Re: cvs commit: src/sys/kern vfs_syscalls.c

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Wed, Aug 17, 2005 at 08:49:43PM +0200, Simon 'corecode' Schubert wrote:
> On 17.08.2005, at 19:50, Joerg Sonnenberger wrote:
> >>Locking nlookup entries doesn't work good enough with NFS so we
> >>absolutely need to pass the rename operation to the server, no matter
> >>what, otherwise we loose atomicity (and might loose files).
> >And now looking back from this point of the discussion, does the
> >behaviour specified by SUS to let it be a NOP make sense or not?
> 
> No, I don't think so.  A success means to me: from the two files "old" 
> and (if existing) "new", only one is remaining afterwards: the 
> associated data (inode) of "old" with the name "new".  This holds true 
> for common renames, for rename("x", "x"), but not for rename("a", "b") 
> if "a" and "b" are hardlinks.  To the user, a rename still is a 
> namespace operation (which can "overwrite" "new").

It might not be the most perfect behaviour, but at the very least it is
the safest thing to do. Note that rename("x", "x") is just a special
case of this as well. Actually, it's interesting to look at which
behaviour is implemented by other systems. OpenBSD 3.4 and Solaris
implement the nop. NetBSD, BSD/OS and Linux the always rename.

I don't care so much about which behaviour is implemented as long it is
guarantied that under no circumstances both links vanish. It should be
kept in mind that a series of rename operations between directories
might trigger exactly that behaviour under softdep, since I don't think
access to multiple directories are serialised with regard to each other.
That's another example for a single filesystem on a native DragonFly
system.

Joerg