summaryrefslogtreecommitdiff
path: root/service_solahart_jakarta_selatan__082122541663/file_locking.mdwn
blob: 27e8cd02f829a7d501dae882b859d6e69f7d05da (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
[[!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

[[service_solahart_jakarta_selatan__082122541663/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"]].