[fcntl]how to lock a file

[Donn Cave]

In article <e1gf6o$74h$1 at emma.aioe.org>, marcello <marcs2006 at gmail.com> 
wrote:

> Carl J. Van Arsdall wrote:
>  > [...]
>  >
>  > If you end up having problems working with the python fcntl module let
>  > me know your configuration I'd be interested to see if anyone else had
>  > similar problems to me.
> 
> 
> Python 2.2.3 (#1, Aug  8 2003, 08:44:02)
> [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-13)] on linux2
> kernel 2.4.21-4.0.1.ELsmp
> glibc-2.3.2-95.6
> 
> 
> 
> What else can i add?

Maybe something about the problem?

There are four functions in that module - fcntl, flock,
ioctl, lockf.  Which one were you using?  What were you
trying to do with it?

Did it raise an exception?  Returned but didn't effectively
interlock against other processes -- on the same host, on
other hosts?  Failed to return when the file should have
been OK to lock?

Is it possible that locks would work fine in a test program,
but fail in your application due to brain damaged POSIX
filesystem locking semantics?

We can start with stuff you probably already know.

- The Berkeley flock(2) function is great but is not
  supported by NFS.

- fcntl(2) F_SETLK etc. are supported by NFS, but have
  extremely inconvenient semantics, part of the POSIX
  1003.1 specifications, particularly the part about losing
  a lock on ANY close(), even if the file descriptor remains
  open for fcntl(2)'s caller.

- lockf(3) is fcntl(2).

- Some platforms provide an flock() that is actually
  fcntl(2), can't think of the right words to express how
  deplorable that practice is.

- On the rare platform that doesn't do this - where they
  are honest enough to just admit that they don't support
  flock() - Python implements fcntl.flock() with fcntl(2),
  I guess on the theory that you can't have enough brain
  damage.  The worst case would be if Python's configure
  missed a bona fide flock(2), which is unlikely but may
  be worth checking if you use flock(2) for a reason.

Donn Cave, donn at u.washington.edu