From owner-freebsd-hackers Sat May 18 7: 2:22 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from sea-incorporated.com (caribbean.sea-incorporated.com [209.74.10.130]) by hub.freebsd.org (Postfix) with ESMTP id 3BC1437B407 for ; Sat, 18 May 2002 07:02:17 -0700 (PDT) Received: from localhost (geoff@localhost) by sea-incorporated.com (8.9.3/8.9.3) with ESMTP id KAA72162; Sat, 18 May 2002 10:02:09 -0400 (EDT) (envelope-from geoff@sea-incorporated.com) Date: Sat, 18 May 2002 10:02:08 -0400 (EDT) From: "Geoffrey C. Speicher" To: Paul Herman Cc: freebsd-hackers@freebsd.org Subject: Re: bug in pw, -STABLE [patch] In-Reply-To: <20020517200005.J912-100000@mammoth.eat.frenchfries.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [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: - 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message