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

["Simon 'corecode' Schubert" <corecode@xxxxxxxxxxxx>]

On 16.08.2005, at 15:43, Joerg Sonnenberger wrote:
> > 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.

You use two different interpretations of "to resolve": one time mapping 
symlinks (and probably `..') into real paths, and the other time 
mapping real paths to inodes.  If the standard was to mean that, they 
would clarify this.  In this context (symlinks) resolving clearly only 
means the former.

I.e. if realpath(old) == realpath(new), then return with success.

cheers
  simon

--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low $$$ NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \

Attachment: PGP.sig
Description: This is a digitally signed message part