* Greg Black <[EMAIL PROTECTED]> [010207 17:33] wrote:
> Alfred Perlstein wrote:
>
> > * Greg Black <[EMAIL PROTECTED]> [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 - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
