From owner-freebsd-hackers Wed Feb 7 17:55:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id E1C4D37B401 for ; Wed, 7 Feb 2001 17:54:58 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f181qNX11438; Wed, 7 Feb 2001 17:52:23 -0800 (PST) Date: Wed, 7 Feb 2001 17:52:23 -0800 From: Alfred Perlstein To: Greg Black Cc: mouss , Tony Finch , Andre Oppermann , Matt Dillon , Rik van Riel , Mike Silbersack , Poul-Henning Kamp , Charles Randall , Dan Phoenix , Jos Backus , freebsd-hackers@FreeBSD.ORG Subject: Re: soft updates and qmail (RE: qmail IO problems) Message-ID: <20010207175223.D26076@fw.wintelcom.net> References: <20010207110208.G74296@hand.dotat.at> <3A805035.C71AAD5E@monzoon.net> <200102061943.f16Jhp365113@earth.backplane.com> <3A805938.96ED890D@monzoon.net> <20010207110208.G74296@hand.dotat.at> <4.3.0.20010207142937.045be410@pop.free.fr> <20010207151647.T26076@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from gjb@gbch.net on Thu, Feb 08, 2001 at 11:33:36AM +1000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Greg Black [010207 17:33] wrote: > Alfred Perlstein wrote: > > > * Greg Black [010207 13:05] wrote: > > > mouss wrote: > > > > > > > At 21:25 07/02/01 +1000, Greg Black wrote: > > > > >Tony Finch wrote: > > > > > > > > > > > Why not just use rename(2)? To protect against the new filename > > > > > > already existing? > > > > > > > > > >Why not just read the man page for rename(2) before making > > > > >suggestions? > > > > > > > > I find nothing convincing in the manpage. Could you please tell > > > > what I am missing. > > > > > > Read the man page, and concentrate on the second sentence under > > > the Description heading. > > > > I'm not sure if the same problem exists for link/unlink and if > > the problem applies to files (not just directories), but there's > > a per-FS flag "in-rename" that prevents concurrant rename(2)s on > > the same FS to prevent a race where something like this can happen: > > > > /a/b/c > > > > /x/y/z > > > > move /a/b to /x/y and at the same time try to move /x/y to /a/b. > > You can't rename /a/b to /x/y or /x/y to /a/b in this situation: > the destination must be empty if it's a directory and you refer > to /a/b/c and /x/y/z. RTFM rename(2). Ugh, you're right, this is how Linux handles the simultanious rename problem (I talked to Viro about it at USENIX). We seem to be able to handle it by just locking the directory node, our IN_RENAME != LINUX_IN_RENAME. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message