From 9f051a2999089763f57b0749a3f6d04a9501be5a Mon Sep 17 00:00:00 2001 From: Joshua Branson Date: Thu, 2 Apr 2026 21:22:38 -0400 Subject: delete file locking pages. POSIX file locking is fixed. Message-ID: <20260403012244.8302-2-jbranso@dismail.de> --- open_issues/file_locking.mdwn | 98 ------------------------------------------- open_issues/visudo.mdwn | 22 ---------- 2 files changed, 120 deletions(-) delete mode 100644 open_issues/file_locking.mdwn delete mode 100644 open_issues/visudo.mdwn (limited to 'open_issues') diff --git a/open_issues/file_locking.mdwn b/open_issues/file_locking.mdwn deleted file mode 100644 index 7dfbdb94..00000000 --- a/open_issues/file_locking.mdwn +++ /dev/null @@ -1,98 +0,0 @@ -[[!meta copyright="Copyright © 2010, 2011, 2014 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]] - -[[!toc]] - - -# Google Summer of Code Project Idea - -[[community/gsoc/project_ideas/File_Locking]]. - - -# visudo - -[[visudo]]. - - -# Existing Work - -[[!GNU_Savannah_patch 332]]. - - -# IRC, freenode, #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) - - -# 2014-03-11 - -[[!message-id "1394523876.28244.11.camel@workhorse-peter-baumgarten-com"]]. diff --git a/open_issues/visudo.mdwn b/open_issues/visudo.mdwn deleted file mode 100644 index 4e87fd8d..00000000 --- a/open_issues/visudo.mdwn +++ /dev/null @@ -1,22 +0,0 @@ -[[!meta copyright="Copyright © 2013, 2014 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]]."]]"""]] - -[[!meta title="visudo: /etc/sudoers is busy, try again later"]] - -[[!tag open_issue_hurd]] - -visudo does not work: - - /etc/sudoers is busy, try again later - -Apparently there is some [[file_locking]] that sudo does which does not -work. Uninvestigated for now. - -One can just edit the /etc/sudoers file and take care of correctness by hand. -- cgit v1.3.1