[Python-bugs-list] [ python-Bugs-229718 ] file locking lossage

[nobody]

Artifact #229718, was updated on 2001-01-22 12:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=229718&group_id=5470

Category: Python Library
Group: None
Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Barry Warsaw
Summary: file locking lossage

Initial Comment:
(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


----------------------------------------------------------------------

Comment By: Nobody/Anonymous
Date: 2001-02-26 19:49

Message:
Logged In: NO 

premise:

- fcntl should be used for locking, not fcntl or lockf,
because of protability
- it requires building a struct whose format is platform
  specific

if so, the posixfile (or equivalent)
functionality is needed for the foreseeable future.


----------------------------------------------------------------------

Comment By: Barry Warsaw
Date: 2001-02-23 11:44

Message:
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.

----------------------------------------------------------------------

Comment By: Donn Cave
Date: 2001-02-08 12:55

Message:
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.)

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr.
Date: 2001-01-26 10:28

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

----------------------------------------------------------------------

Comment By: Nobody/Anonymous
Date: 2001-01-22 13:25

Message:
(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

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=229718&group_id=5470