Failed thumb generation can leave a temp file behind in the content folder

[afbora]

@afbora @bastianallgeier One edge case I noticed: the catch (Throwable $e) cleanup won't run if process() is killed by a PHP memory_limit or max_execution_time fatal error, since those aren't catchable. In that case $tempRoot is left behind for good. I've seen this happen with a large create resize (e.g. 2500×2500) on high-megapixel uploads. The leftover file then also shows up as a stray file in the folder, and Kirby can no longer tell which template/blueprint it belongs to.

Maybe it would help to write the temp file to a separate folder instead of next to the original, so it can't be mistaken for a real content file even if it's not cleaned up.

Originally posted by @ennemoserandre in #8074 (comment)

[afbora]

@ennemoserandre You're right, this is a valid issue. When PHP hits the memory limit it stops immediately, so the cleanup never runs and the temp file is left behind.

Possible solution

One possible fix would be to prefix the temp file with a dot, e.g. .myimage.tmp-123.jpg. Kirby already skips dot files when indexing, so a leftover wouldn't show up as a stray file anymore.

On top of that we could clean up old leftovers the next time the same file is processed — only ones older than an hour, so a temp file that's still in use doesn't get removed.

Let me know what you think.

[ennemoserandre]

@afbora I think this solution works for me, though I'm not too familiar with how Kirby indexes files internally. Prefixing the temp file with a dot sounds like a solid approach — good to hear Kirby already ignores dot files when indexing, so that avoids the stray-file issue cleanly.

Cleaning up leftovers older than an hour the next time the file is processed also sounds like a good safety net, and the one-hour threshold seems reasonable to avoid touching files that are still actively in use.

Sounds good to me!