cvs commit: src/sys/kern vfs_syscalls.c

[Joerg Sonnenberger]

On Tue, Aug 16, 2005 at 12:40:37PM -0700, Matthew Dillon wrote:
>     Uh, no.  The part about the files being the same is clearly
>     NOT about symlinks at all.  Those are a random tumble of disjoint
>     requirements, they are not related to each other in any way.  Rename
>     does NOT resolve symlinks.  It never has, it never will.

Fully aggred.

>     They also can't be refering to hardlinks, or the standard would say
>     hardlinks.

The standard *never* says hardlinks either. It is always talking about
directory entries or links.

>     They have to be refering to the paths resolving to the same
>     identical namespace, in which case we are right, linux is right,
>     and FreeBSD is wrong. 

"Resolving to the same existing file" leaves the pure namespace, because
the standard differenciates between files (UFS: inode) and directory
entries.

>     It's simple and straightfoward, not ultra complex.  It is not
>     rename's responsibility to validate or resolve symlinks, or to
>     treat hardlinks as a special case.  rename is entirely a namespace
>     operation.  The only requirements are that it disallow impossible
>     combinations, such as trying to rename a file over a directory,
>     or rename a directory into a sub-directory of itself.

As soon as the "new" operand already exists it is not a pure namespace
operation anymore. What happens if two NFS clients have the directory
cached, the first issues "mv a b", the second "mv b a"? Are both clients
issuing remove operations with the new code?

Joerg