Use lock-files in the way git does with auto-cleanup being the most notable feature.

• writable lock files that can be committed to atomically replace the resource they lock
• read-only markers that lock a resource without the intend to overwrite it
• auto-removal of the lockfiles and intermediate directories on drop or on signal

lib.rs:

git-style registered lock files to make altering resources atomic.

In this model, reads are always atomic and can be performed directly while writes are facilitated by the locking mechanism implemented here. Locks are acquired atomically, then written to, to finally atomically overwrite the actual resource.

Lock files are wrapped gix-tempfile-handles and add the following:

• consistent naming of lock files
• block the thread (with timeout) or fail immediately if a lock cannot be obtained right away
• commit lock files to atomically put them into the location of the originally locked file

Limitations

• All limitations of gix-tempfile apply. A highlight of such a limitation is resource leakage which results in them being permanently locked unless there is user-intervention.
• As the lock file is separate from the actual resource, locking is merely a convention rather than being enforced.