Delete released lock files on unix

[spokorski]

After they are released, an attempt is made to delete the lock files in both the WindowsFileLock and SoftFileLock classes, but not in UnixFileLock. Is there a reason this is missing from UnixFileLock? It seems strange that lock files clean up after themselves on some systems but not on others.

[AdorablePotato]

Ups, there's no reason for that, I simply forgot to clean up.
Thank you for the patch!

[RPiAwesomeness]

I'm not sure if I'm doing this incorrectly but it appears that this is happening again on Ubuntu for version 3.0.4. I can see the debug messages coming through and it seems to be acquiring, locking, and releasing correctly, but there are a bunch of .lock files still laying around.

Currently I'm using the following:

lock_path = out_path + ".lock"
lock = FileLock(lock_path)

try:
    with lock.acquire(timeout=10):
        ...
except Timeout as e:
    ....

Looking at the source it appears that you removed this functionality again?
https://filelock.readthedocs.io/en/latest/_modules/filelock.html#UnixFileLock

[int-ua]

3.0.12 affected. Please reopen. SoftFileLock works as expected.

[charles-dyfis-net]

This feature request is extremely harmful.

Deleting lockfiles on UNIX causes a race condition. Consider the following set of events:

• Program A creates and opens (as an atomic operation) a file A.lck.
• Program A grabs a lock on the file handle it holds on that file; this operation succeeds.
• Program B opens A.lck.
• Program B requests a lock on the file handle; this operation blocks.
• Program A deletes A.lck.
• Program A closes its file handle, which makes program B able to get a lock on the file handle it already holds, on the now-deleted copy of A.lck.
• Program C creates and opens (as an atomic operation) a new file under the name A.lck.
• Program C grabs a lock on the file handle it holds on this file; because they're two different files (even if under the same name), this succeeds.

...thus, you have both programs B and C thinking they hold the same lock.

---

On Windows this can't happen, because directory entries can't be deleted until no handles on the files that back them exist. That's untrue on UNIX; thus, different behavior is required.