From owner-freebsd-hackers Sat May 18 11:17:36 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.deltanet.com (mail.deltanet.com [216.237.144.132]) by hub.freebsd.org (Postfix) with ESMTP id A69E437B41C for ; Sat, 18 May 2002 11:17:27 -0700 (PDT) Received: from mammoth.eat.frenchfries.net (da001d0852.lax-ca.osd.concentric.net [64.0.147.85]) by mail.deltanet.com (8.11.6/8.11.6) with ESMTP id g4IHudO20896 for ; Sat, 18 May 2002 10:56:41 -0700 Received: by mammoth.eat.frenchfries.net (Postfix, from userid 1000) id F294B4DDB; Sat, 18 May 2002 11:15:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mammoth.eat.frenchfries.net (Postfix) with ESMTP id DBA004DC8; Sat, 18 May 2002 11:15:58 -0700 (PDT) Date: Sat, 18 May 2002 11:15:58 -0700 (PDT) From: Paul Herman X-X-Sender: pherman@mammoth.eat.frenchfries.net To: "Geoffrey C. Speicher" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: bug in pw, -STABLE [patch] In-Reply-To: Message-ID: <20020518110125.Q410-100000@mammoth.eat.frenchfries.net> 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 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message