cvs commit: src/sys/kern vfs_syscalls.c

[Joerg Sonnenberger]

On Tue, Aug 16, 2005 at 02:56:19PM +0200, Simon 'corecode' Schubert wrote:
> On 16.08.2005, at 14:24, Joerg Sonnenberger wrote:
> 
> >On Tue, Aug 16, 2005 at 12:31:32PM +0200, Simon 'corecode' Schubert 
> >wrote:
> >>On 15.08.2005, at 18:01, Joerg Sonnenberger wrote:
> >>>That is exactly the behaviour the standard wants to avoid. The 
> >>>wording
> >>>of SUS is also pretty clear, "resolve to the same existing name" does
> >>>mean nothing less than having the same inode for a traditional Unix
> >>>filesystem. I also won't say this behaviour is counter-intuitive, it
> >>>makes as much sense as just dropping the old node.
> >>
> >>The standard is clear to me: it doesn't talk about links, but symbolic
> >>links.
> >No, it has been talking about symlinks explicitly before.
> 
> Exactly.  Re-reading the standard, it isn't just clear: it's absolutely 
> clear.  This is just about symlinks.

SUS:
If either the old or new argument names a symbolic link, rename() shall
operate on the symbolic link itself, and shall not resolve the last
component  of the argument. If the old argument and the new argument
resolve to the same existing file, rename() shall return successfully
and perform no other action.

Interpretation:
If old or new is a symlink, all but the last companent of the argument
is resolved. The result are two pairs (directory, last component). If
those two resolve to the same file (as in inodes pointed to by the entry
"last component" in "direcory"), it shall return successfully without
any other action.

Joerg