[Python-bugs-list] [Bug #129718] file locking lossage

[noreply@sourceforge.net]

Bug #129718, was updated on 2001-Jan-22 12:43
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : bwarsaw
Summary: file locking lossage

Details: (reference:
http://www.erlenstar.demon.co.uk/unix/faq_3.html#SEC35)

there are 4 ways to lock a file in unix.
fcntl, lockf, flock and dotlocking.

the only portable ways are fcntl and dotfiles. dotlocking
is more nfs-resistant. (actually the only reliable
nfs-resistant way seems to be a combination.
see eg.
http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=43491)

both fcntl and dotlock require magic incantations to
implement. therefore it is desireable to include code
to do this in the standard python library.

there is only one module in the python distribution
that implements dot-locking or fcntl() locking:
the posixfile module.

however, it is marked as obsolete(!) because someone
misguidedly thinked the sysv lockf is more portable.

this leads to a situation where the most sensible
low-effort way to implement file locking is to
either cut-n-paste code from the posixfile module,
or to call an external program (such as lockfile(1)
from the procmail package) to do it.

  -- Erno Kuusela
     erno@iki.fi


Follow-Ups:

Date: 2001-Feb-08 12:55
By: donnc

Comment:
It isn't the prettiest thing in Python, but
I wouldn't have thought fcntl.lockf() would
be such a problem.  I get lockf() even on Ultrix!
In every case I can find, it's implemented per
X/Open to make the same locks as fcntl(), so the
choice between one or the other is only API.
Is it worse than I know?  (I'm just a mildly
interested member of the general Python user
public, not speaking for anyone.)
-------------------------------------------------------

Date: 2001-Jan-26 10:28
By: fdrake

Comment:
Assigned to Barry, since he deals with file locking the most these days.
-------------------------------------------------------

Date: 2001-Jan-22 13:25
By: nobody

Comment:
(i apologise for the irritated tone of the above
report.)

it apperas the approach used in posixfile is not so bullet-proof either. in
addition of the layout of the flock struct being platform-dependent,
it is also (at least on linux) dependent also
of the compilation mode used. if python
is compiled with a 64-bit file offsets,
the start and len members can grow in size.
so this would either need to be done in c code
or the code should test for the file offset
size (i don't know if it's possible to find this
out in python code).

  -- erno
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129718&group_id=5470