cvs commit: src/sys/kern vfs_syscalls.c

Wed Aug 17 07:34:31 PDT 2005

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00021.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: This is a digitally signed message part"
URL: <http://lists.dragonflybsd.org/pipermail/commits/attachments/20050817/1e1150b3/attachment-0020.obj>