Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 08 Feb 2001 11:33:36 +1000
From:      Greg Black <gjb@gbch.net>
To:        Alfred Perlstein <bright@wintelcom.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:  <nospam-3a81f770b20cef3@maxim.gbch.net>
In-Reply-To: <20010207151647.T26076@fw.wintelcom.net>  of Wed, 07 Feb 2001 15:16:47 PST
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> 

next in thread | previous in thread | raw e-mail | index | archive | help
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).


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?nospam-3a81f770b20cef3>