On Sat, 18 May 2002, Geoffrey C. Speicher wrote: > > > The file isn't actually unlinked until p1 closes the fd > > > > 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().
Well, unlink and remove are the same in my vocabulary. The file is removed when you unlink it, but the will lock remain until you close it. > 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 p2 blocks until p1 closes the fd. The problem in this example is, by the time p2 gains the lock, the file in non-existant in /var/lock, which allows p3 to grab a new 2nd lock, which gives you the corruption. You should open() with O_NONBLOCK in order to solve your problem, but the calling process will fail. In that case, pw should exit with a sysexits(3) error to notify the caller. Having pw loop for a few seconds while trying to obtain the lock (like lockf(1) does) might be nice. -Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
