Core

I've seen this behaviour and I'm currently trying to figure out what the cause is. I suspect some race condition.

This is a race condition reported here already:
http://forge.typo3.org/issues/24342

There is indeed a problem that appears when the lock file could not be acquired, as reported in this syslog (after slightly modifying Core to add additional information):

05-12-11 15:24 - cms: Locking: Failed to acquire lock: Lock file could not be created
(/path/to/typo3temp/locks/f288221509d8f33b8e85fbfd25731733)
05-12-11 15:24 - Core: Error handler (FE): PHP Warning: unlink(/path/to/typo3temp/locks/
f288221509d8f33b8e85fbfd25731733) [<a href='function.unlink'>function.unlink</a>]: No such
file or directory in /path/to/t3lib/class.t3lib_lock.php line 21

The non-acquired lock-file is then "unlinked" by taking for granted that it exists. By quickly digging into the code, I'd say that fixing that would require quite some refactoring of t3lib_lock, refactoring that is supposed to happen with #24342 but was forgotten (as not pushed forwards) for 4.6, thus hopefully something for 4.7.

Anyway, I would suggest to simply test for file existence before unlinking it but not hide the warning with an @ sign in front of unlink.

Does testing if file exists solve the race condition problem? Does it related to the php unlink() function?

What about adding the @ sign in front of unlink instead of testing with file_exists. I'd say that even if not "that clean", it will prevent perform 2 accesses for the file system in most cases...

Patch set 1 for branch TYPO3_4-6 has been pushed to the review server.
It is available at http://review.typo3.org/12832