LatchfileDocumentation

Concurrency

Atomic replacement protects a single file from partial reads. When two tasks both read, edit, and replace the same file, whichever task renames last wins.

The counter that lost count

Two workers read 42, both compute 43, and both publish 43. Each file is perfectly valid. A whole update still went missing.

Serialize read–modify–write

Within a process, hold a mutex around the complete read, modify, and publish sequence. Across processes, agree on a lock file whose name stays stable. Locking the destination itself can break coordination when the destination is replaced by a new file.

Readers and long-lived handles

Open the file again when you need a fresh snapshot. A live file descriptor continues to refer to the old file on Unix after the name points to the new one. A watcher should observe the containing directory and reopen the file when the name changes.