cvs commit: src/sys/kern vfs_syscalls.c

[Simon 'corecode' Schubert]

On 16.08.2005, at 22:37, Joerg Sonnenberger wrote:
    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.
Yes that's true.  It talks either about symbolic links or links 
(meaning hard links i guess).  Yet I don't see why resolve should one 
time mean pathname->inode and the other time 
path-with-symlinks-or-relative->pathname

    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.
Wrong interpretation in my eyes.

    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?
Do the clients issue remove operations?  I was thinking they just send 
"rename a to b" the server, which in turn does the job.

NFS is not a good example anyways because it operates with 
maybe-outdated data.

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: pgp00022.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/be021a50/attachment-0022.obj>