[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: Closed
Resolution: Wont Fix
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-23 11:44
By: bwarsaw

Comment:
I'm not entirely sure what the bug is that you're reporting.  
Are you saying that posixfile should not be marked as obsolete?  I recently
made some minor changes (docs and symbols) to fcntl to make lockf more
understandable.

IMO, file locking is so application and platform dependent that it isn't
very useful to have higher level modules available in the standard library.
 E.g., I have a LockFile module in Mailman which is nfs-resistant, but also
supports lock breaking semantics (at the expense of occasionally stale
locks).

Thus, I think the posixfile documentation is fine, and lockf is useful in
some situations (and does work fine, at least on Linux).  So I think there
is no bug here.  If you disagree, and think posixfile should not be marked
as obsolete, please follow up to this comment and I'll reassign to Fred.
-------------------------------------------------------

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