rename: Rename to pathname ($newName) that already exists

[adrianbj]

I am occasionally seeing these errors.

rename: Rename to pathname ($newName) that already exists: /var/www/html/site/assets/files/48889/assets.1080x1080-srcset.png.webp
rename: Rename to pathname ($newName) that already exists: /var/www/html/site/assets/files/48889/assets.1080x1080-srcset.png
rename: Rename to pathname ($newName) that already exists: /var/www/html/site/assets/files/48889/assets.800x0-srcset.png.webp
rename: Rename to pathname ($newName) that already exists: /var/www/html/site/assets/files/48889/assets.800x0-srcset.png
rename: Rename to pathname ($newName) that already exists: /var/www/html/site/assets/files/48889/assets.600x0-srcset.png.webp
rename: Rename to pathname ($newName) that already exists: /var/www/html/site/assets/files/48889/assets.600x0-srcset.png

Does the module maybe need a file_exists() check before creating?

Let me know if you need anymore information.

Thanks!

[chriswthomson]

Hi @adrianbj,

My suspicion is that this error is happening here:

PageimageSource/PageimageSource.module

Line 260 in abbef7a

$img = $img->size($img->width, $img->height, $options);

At this point it is trying to use the original image (or variation - the Pageimage that srcset is called on) but applying the module options to it. Perhaps it's possible to check or do a dry run on the size() call. I'll have a look and see what I can do.

Cheers,

Chris

[adrianbj]

Hi @chriswthomson - I am still seeing this all the time - did you manage to find time to take a look?

Thanks!

[chriswthomson]

Hi @adrianbj,

Apologies for the delay. I'm still not sure what's causing this. I've checked a few sites we use the module on and we're seeing the same errors being logged to the files-errors log.

Having reviewed Pageimage::size() it looks to me that it should already be checking whether the image exists before it attempts the rename(). I'll need a bit of advice from Ryan on this one, will post in the message board shortly.

[adrianbj]

Hi @chriswthomson - Claude's come up with this:

I dug into this and I'm fairly confident it's a benign race condition rather than anything PageimageSource is doing wrong.

The log entries come from WireFileTools::rename() (wire/core/WireFileTools/WireFileTools.php), which logs "Rename to pathname ($newName) that already exists" and returns false whenever the destination already exists. It gets triggered inside Pageimage::size() when generating the srcset variations:

1. Two requests hit the same page at roughly the same time (visitors, bots, or just multiple images rendering).
2. Both pass the !$filenameFinalExists check in Pageimage::size() because neither variation exists yet.
3. Both resize into their own temp file, then both try to rename() temp → final.
4. The first one wins; the second finds the final already exists, so rename() logs the error and returns false.

Core already anticipates this for the main (non-webp) rename — if the rename fails but the final exists, it silently treats it as "another request won." But WireFileTools::rename() logs the error before returning false, so the files-errors log still fills up. And the webp rename has no race guard at all, which is why we see both the .png and .png.webp entries.

So PageimageSource isn't at fault — it just generates a lot of variations, which increases the odds of concurrent collisions and makes this surface much more often. Chris, your hunch about that area of the module was close, but the dimensions don't actually matter; any concurrently-requested variation can collide.

The clean fix is in core: re-check file_exists() immediately before each rename and discard the temp copy instead of attempting a rename into an existing destination (which is what logs the error). Something like this in Pageimage::size():

  if($sizer->resize($width, $height)) {
      if($options['webpAdd'] && $options['webpOnly']) {
          if(is_file($filenameUnvalidated)) $files->unlink($filenameUnvalidated);
      } else {
          clearstatcache();
          if(file_exists($filenameFinal)) {
              // race condition: another request already created this variation,
              // discard our temp copy rather than attempting a rename that would log an error
              $files->unlink($filenameUnvalidated, true);
          } else if(!$files->rename($filenameUnvalidated, $filenameFinal)) {
              if($files->exists($filenameFinal)) {
                  // potential race condition: another request won
              } else {
                  $this->error = "Rename failed: $filenameUnvalidated => $filenameFinal";
              }
          }
      }
      if($options['webpAdd'] && file_exists($filenameUnvalidatedWebp)) {
          clearstatcache();
          if(file_exists($filenameFinalWebp)) {
              // race condition: another request already created the webp variation
              $files->unlink($filenameUnvalidatedWebp, true);
          } else {
              $files->rename($filenameUnvalidatedWebp, $filenameFinalWebp);
          }
      }
  }

That stops the log spam for both the regular and webp variations in the common case, and the existing $files->exists($filenameFinal) guard still covers the tiny remaining window.

[chriswthomson]

Thanks @adrianbj, I've updated my forum post to note that you've posted this here.

[adrianbj]

Thanks @chriswthomson - do you think a GH issue on PW might be the best approach here? I know that Ryan often missing pings in the forum. I can post if you like?

[chriswthomson]

Hi @adrianbj, yes ok that's probably a good idea, go for it!

[adrianbj]

processwire/processwire-issues#2257