[I'm bringing the discussion back to -hackers, since it was omitted in
your original reply, Paul. To get everyone up to speed, Paul suggested
that calling unlink() _before_ close() should solve the race condition
mentioned in my original message. However, that still leads to
corruption, and we're trying to figure out why.]
On Fri, 17 May 2002, Paul Herman wrote:
> > The file isn't actually unlinked until p1 closes the fd
>
> Sure it is. Try a little C:
>
> fd = open("watchme", O_CREAT|O_EXLOCK);
> sleep(10);
> unlink("watchme");
> sleep(10);
> close(fd);
>
> You'll see the file disappear after 10 seconds, not 20.
Hmm. Rechecking the man page for unlink(2) I see that I worded the above
incorrectly. The file is unlinked when you unlink(), but not actually
removed until close().
> Also, open() looks like it blocks until it can get the lock
But when does open() block in the following scenario?
p1:open() - open & lock file
p2:open() - BLOCK
p1:unlink() - remove link only, do not remove file
p2:open() - WAKEUP
p1:close() - close fd
Does it block before it opens a fd, or after then but before it gains an
exclusive lock? In other words, did p2 open a new file after it woke up,
or did it open the same file that p1 had opened? If the latter is true
then we could extend the above:
p3:open() - open & lock file (since p1 unlinked p1 & p2's copy)
p2/p3:<update master.passwd> - BOOM
If the former is true, then I'm pretty much out of ideas. I don't think
the corruption is due to something else, since simply removing the call to
unlink() does in fact fix the problem.
Geoff
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
