--- .../gsoc/project_ideas/file_locking.mdwn | 47 --------- open_issues/file_locking.mdwn | 98 ------------------- open_issues/visudo.mdwn | 22 ----- 3 files changed, 167 deletions(-) delete mode 100644 community/gsoc/project_ideas/file_locking.mdwn delete mode 100644 open_issues/file_locking.mdwn delete mode 100644 open_issues/visudo.mdwn
diff --git a/community/gsoc/project_ideas/file_locking.mdwn b/community/gsoc/project_ideas/file_locking.mdwn deleted file mode 100644 index 602c643e..00000000 --- a/community/gsoc/project_ideas/file_locking.mdwn +++ /dev/null @@ -1,47 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009, 2012, 2014, 2018 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="Fix and Complete File Locking Support"]] - -[[!template id=highlight text="""/!\ Obsolete /!\ - ---- - -Svante Signell revived the patch and fixed it, it is now committed"""]] - - -Over the years, [[UNIX]] has acquired a host of different file locking mechanisms. -Some of them work on the Hurd, while others are buggy or only partially -implemented. This breaks many applications. - -The goal is to make all file locking mechanisms work properly. This requires -finding all existing shortcomings (through systematic testing and/or checking -for known issues in the bug tracker and mailing list archives), and fixing -them. The biggest missing feature is record locking, i.e. the lockf variant, -which needs a complete implementation. - -This task will require digging into parts of the code to understand how file -locking works on the Hurd. Only general programming skills are required. - -A preliminary patch is [[!GNU_Savannah_patch 332 desc="available"]]. - -Exercise: Find one of the existing issues, either by looking at the task/bug -filed on [[open_issues/file_locking]], on -trackers on savannah, or by trying things out yourself; and take a go at it. -Note though that most of these issues are probably not trivial -- it's quite -likely that you won't be able to actually fix any of them in the time available -during the application process. However, you might be able to spot something -else that could be improved while looking into this. - -If after trying for a while you haven't found anything easy enough to improve -in the locking-related code, talk to us about some alternative exercise task. -Perhaps you actually find something you could do while looking through the bug -tracker or trying stuff yourself in search of locking 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 - - <pinotree> youpi: i found the issue with python-apt - <pinotree> s/with/of/ - <youpi> good! - <pinotree> lock file issue, though :/ - <youpi> :/ - <pinotree> this is the sample test case, derived from apt's code: - http://paste.debian.net/103536/ - <pinotree> basically, it seems asking for a file lock in the same process - where there's already such lock on the file, fails - <pinotree> youpi: ↑ - <youpi> uh, posix doesn't even define some nesting - <pinotree> it seems it just talks about concurrency with other processes - <youpi> posix tells more about it later - <youpi> saying that if a lock already exists, then it is replaced by the - new - <youpi> (when inside the same process) - <pinotree> yay, found a bug in hurd :p - <youpi> well, actually it's known - <youpi> i.e. setlk is completely bogus, based on flock - <youpi> and flock doesn't have the same semantic in that regard - <youpi> so we can't fix it without really implementing setlk - <pinotree> the XXX comment in glibc/sysdeps/mach/hurd/fcntl.c, by chance? - :) - <youpi> of course :) - <pinotree> youpi: hm, flock's man page says: - <pinotree> "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." - <pinotree> so a new lock in the same process over the original lock should - replace the old one? - <youpi> uh, that's not what I had seen - <pinotree> http://linux.die.net/man/2/flock - <youpi> An attempt to lock the file using one of these file descrip- - <youpi> tors may be denied by a lock that the calling process - has already - <youpi> placed via another descriptor. - <youpi> so it's really not that easy - <pinotree> that's in case of trying to create a lock on a file with a - different fd than the existing lock - <youpi> that's what your testcase does - <pinotree> which, hm, is python-apt's case - <youpi> that being said, the sentence I pasted does not seem to appear in - posix - <pinotree> flock() does not seem posix - <youpi> it may have been the behavior of Linux at some point in the past - <youpi> it's not , but F_SETLK is - <youpi> and in linux world, flock <=> F_SETLK, iirc - <youpi> in glibc world, even - <youpi> (just checked it, see sysdeps/posix/flock.c - <youpi> pinotree: I guess your testcase works on Linux? - <pinotree> which means we should get a proper F_SETLK working, and then - just use this flock version (instead of the custom one), no? - <pinotree> yes, it works on linux (and on kfreebsd, see that python-apt - builds) - <youpi> no, I mean our flock() should probably be happy with locking part - of a file several times - <youpi> (that is, hurd's file_lock() RPC) - <youpi> ah, no, on Linux flock is its own system call - <youpi> (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. -- 2.53.0
