locking files on Linux

Nobody nobody at nowhere.com
Fri Oct 19 10:36:38 EDT 2012


On Thu, 18 Oct 2012 14:44:27 +0100, andrea crotti wrote:

> Uhh I see thanks, I guess I'll use the good-old .lock file (even if it
> might have some problems too).

In which case, you don't see. A lock file is also advisory, i.e. it only
affects applications which explicitly check for a lock file.

Historically, the advantage of lock files was that they worked on NFS
implementations which didn't implement locking (it's a long-standing Unix
joke that "NFS" stands for "Not a FileSystem", because it failed to
conform to established filesystem semantics).

Nowadays, NFS implementations which don't support locking are sufficiently
rare that they can safely be ignored. So lock files don't offer any
advantages, and one fairly obvious disadvantage (the possibility of a
"stale" lock file if the program terminates unexpectedly without removing
the lock file).

For any form of advisory locking, the one thing which matters is that all
progams which access the file agree on the mechanism used, i.e. whether to
use lockf(), fcntl(), flock() (locks created by one mechanism may or may
not be recognised by the others), or lock files, and in the case of lock
files, the naming convention which is used.

If the file is specific to a particular program, and you just need to
protect against multiple instances of that program, you can use whichever
mechanism you wish, and would be strongly advised to use kernel locks
(fcntl() is the most portable, followed by lockf(); flock() is a BSD-ism).




More information about the Python-list mailing list