Bill Allombert wrote: > There are also issues with NFS to consider. flock has worked over NFS since Linux 2.6.12, which was released in June 2005, making it more than 20 years old. Some of the text in Policy that tries to account for locks "not working" on NFS is deeply outdated in that regard. I think it's safe to say that flock on NFS is better than other potential alternatives (including existence-based lockfiles).
There are, of course, still some filesystems that flock doesn't work on; if nothing else, an arbitrarily broken FUSE filesystem could do that. I would argue that it's reasonable for programs to assume that /dev will support locking, that it's possible for programs to tell the difference between "locking works and I didn't acquire the lock" and "locking doesn't work", and that in the latter case programs can choose (based on what they use locking for) whether they want to fail and notify the user, warn and proceed anyway, or try falling back to a well-defined proxy location on another filesystem before giving up (e.g. `$XDG_RUNTIME_DIR`, where locks will also always work). I don't think Policy should cover exact procedures there, but I think it'd be reasonable for Policy to cover "locks must work on /dev and on $XDG_RUNTIME_DIR", and lump the rest in with other deference to "if coordinating software all agrees" together with the *hint* of potentially locking a (non-existence-based) lockfile in a proxy location.
