[Python-bugs-list] [ python-Bugs-485342 ] fcntl.lockf broken?

[noreply@sourceforge.net]

Bugs item #485342, was opened at 2001-11-25 09:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485342&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: fcntl.lockf broken?

Initial Comment:
fcntl.lockf appears broken to me. It always gives me
"bad file descriptor", even though I can use the file
object from which it is derived:

>>> import fcntl
>>> f = open("names.db", "r")
>>> fcntl.lockf(f.fileno(), fcntl.LOCK_EX)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 9] Bad file descriptor
>>> data = f.read()
>>> len(data)
45056

Since posixfile is officially deprecated, this would
be nice to have working...

Environment: Mandrake 8.1, gcc 2.96, glibc 2.2.4


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

>Comment By: Skip Montanaro (montanaro)
Date: 2001-11-25 09:13

Message:
Logged In: YES 
user_id=44345

I retract my contention that there is a bug in lockf.  It
appears that you can't ask for an exclusive lock on a
file which is open for read access.  As it's not clear
from either the fcntl module documentation or the fcntl,
lockf or flock man pages (just what does fcntl.lockf
emulate by the way?), perhaps something simple should
be added to the fcntl.lockf description.  Suggestion:

    On at least some systems, LOCK_EX can only be used
    if the file descriptor refers to a file opened for
    writing.



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

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