Date: Wed, 7 Feb 2001 17:52:23 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Greg Black <gjb@gbch.net> Cc: mouss <usebsd@free.fr>, Tony Finch <dot@dotat.at>, Andre Oppermann <oppermann@monzoon.net>, Matt Dillon <dillon@earth.backplane.com>, Rik van Riel <riel@conectiva.com.br>, Mike Silbersack <silby@silby.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Charles Randall <crandall@matchlogic.com>, Dan Phoenix <dphoenix@bravenet.com>, Jos Backus <josb@cncdsl.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: soft updates and qmail (RE: qmail IO problems) Message-ID: <20010207175223.D26076@fw.wintelcom.net> In-Reply-To: <nospam-3a81f770b20cef3@maxim.gbch.net>; from gjb@gbch.net on Thu, Feb 08, 2001 at 11:33:36AM %2B1000 References: <20010207110208.G74296@hand.dotat.at> <Pine.LNX.4.21.0102061555550.1535-100000@duckman.distro.conectiva> <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> <nospam-3a81b8a9470c94a@maxim.gbch.net> <20010207151647.T26076@fw.wintelcom.net> <nospam-3a81f770b20cef3@maxim.gbch.net>
next in thread | previous in thread | raw e-mail | index | archive | help
* Greg Black <gjb@gbch.net> [010207 17:33] wrote: > Alfred Perlstein wrote: > > > * Greg Black <gjb@gbch.net> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010207175223.D26076>