PHP Warning: unlink() ... No such file or directory

[seirerman]

Bug Report

Current Behavior
I get a lot of errors like this in my log:

PHP Warning: unlink(/var/html/t3/web/typo3temp/assets/tx_staticfilecache/https_www.domain.com_443/path/to/some/page/.htaccess): No such file or directory in /var/html/t3/vendor/lochmueller/staticfilecache/Classes/Service/RemoveService.php line 41

Sometimes hundreds of them for different files at the same time, flooding the log.

It's a big site with dozens of editors working simultaneously. My theory is that when an editor saves a record and triggers SFC to delete a lot of cache files (which could take a few seconds) and then another editor (maybe even the same?) does the same right after that, some of the files have already been deleted and SFC can't find them anymore.

I haven't been able to reproduce this, yet.

Environment

• TYPO3 version(s): 13.4.19
• staticfilecache version: 15.2.3
• Is your TYPO3 installation set up with Composer (Composer Mode): yes

[lochmueller]

Hey @seirerman

thanks for reporting. Do you try to add some locking mechanism in the remove process. Perhaps this avoid the Race conditions in your case.

Regards,
Tim

[seirerman]

I didn't, no.

I don't get feedback from editors for this, because they don't see the warnings.
But I was able to trigger the errors by myself, though, by simply moving a page in the pagetree. The page I moved still has the same parent page, so I basically only changed the sorting value in the pages table.
But the unlink error where not related to the page I just moved, but from different sites all over the page tree.

When I did the same thing later no warnings were logged, so actually reproducing this is still difficult.

[lochmueller]

Hey @seirerman

moving a page could be the problem, that a "locking" would fix. Moving pages in TYPO3 remove the cache of multiple pages after another. If there are two processes that delete the cache at the same time, this problem could occur. I will check this and add some locking in the next days/weeks. Perhaps we could this directly with this change: #453 to streamline the access of the caching backends.

Beste Grüße,
Tim