[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[!tag open_issue_hurd open_issue_glibc]] IRC, #hurd, 2010-12-31. youpi: i found the issue with python-apt s/with/of/ good! lock file issue, though :/ :/ this is the sample test case, derived from apt's code: http://paste.debian.net/103536/ basically, it seems asking for a file lock in the same process where there's already such lock on the file, fails youpi: ↑ uh, posix doesn't even define some nesting it seems it just talks about concurrency with other processes posix tells more about it later saying that if a lock already exists, then it is replaced by the new (when inside the same process) yay, found a bug in hurd :p well, actually it's known i.e. setlk is completely bogus, based on flock and flock doesn't have the same semantic in that regard so we can't fix it without really implementing setlk the XXX comment in glibc/sysdeps/mach/hurd/fcntl.c, by chance? :) of course :) youpi: hm, flock's man page says: "A process may only hold one type of lock (shared or exclusive) on a file. Subsequent flock() calls on an already locked file will convert an existing lock to the new lock mode." so a new lock in the same process over the original lock should replace the old one? uh, that's not what I had seen http://linux.die.net/man/2/flock An attempt to lock the file using one of these file descrip- tors may be denied by a lock that the calling process has already placed via another descriptor. so it's really not that easy that's in case of trying to create a lock on a file with a different fd than the existing lock that's what your testcase does which, hm, is python-apt's case that being said, the sentence I pasted does not seem to appear in posix flock() does not seem posix it may have been the behavior of Linux at some point in the past it's not , but F_SETLK is and in linux world, flock <=> F_SETLK, iirc in glibc world, even (just checked it, see sysdeps/posix/flock.c pinotree: I guess your testcase works on Linux? which means we should get a proper F_SETLK working, and then just use this flock version (instead of the custom one), no? yes, it works on linux (and on kfreebsd, see that python-apt builds) no, I mean our flock() should probably be happy with locking part of a file several times (that is, hurd's file_lock() RPC) ah, no, on Linux flock is its own system call (which is independant from lockf from the locking point of view, iirc)