[Mailman-Developers] Revisiting file locking

[John Viega]

On Tue, May 05, 1998 at 03:45:47PM -0400, Barry A. Warsaw wrote:
> 
> I wasn't able to dig up the Netscape Mail + File Locking article that
> Jamie Zawinski wrote.  I don't seem to have it in my bookmarks or
> easily grepable and a web search turned up only stale links.  I
> emailed Jaime to see if he's got an updated link and will forward that 
> if I get a response.

Hmm, I got it on a web search:
http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/movemail.html


> If I remember correctly, the article basically justifies the point of
> view that the best portable way to do resource locking across NFS is
> by creating a file with O_CREAT | O_EXCL.  That's what's meant by
> "dot-file" locking because you usually create a .file that is mostly
> invisible. 

I have yet to find much on whether there are race conditions w/ O_EXCL
and directories.  However, the open() man page on my system has the
following to say:

     O_EXCL When used with O_CREAT, if the file already  exists
              it  is  an error and the open will fail.  O_EXCL is
              broken on NFS file systems, programs which rely  on
              it for performing locking tasks will contain a race
              condition.  The solution for performing atomic file
              locking using a lockfile is to create a unique file
              on the same fs (e.g.,  incorporating  hostname  and
              pid),  use  link(2)  to make a link to the lockfile
              and use stat(2) on the unique file to check if  its
              link  count  has  increased  to  2.  Do not use the
              return value of the link() call.

The problem with this solution is, what happens if a process dies
while holding a lock?  The most straightforward solution is to drop a
pid into the lock file, and have the process wishing to grab the lock
check to see if the process is still running.  

Also, this is a polling-based solution, which isn't incredibly
desirable either...  But I guess there's no way around that one.

Ok, I'll implement a general library call for this one, I guess.

BTW, No one has put any effort into making pipermail portable yet,
have they?

John