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