cvs commit: src/sys/kern vfs_syscalls.c

[Simon 'corecode' Schubert]

On 15.08.2005, at 12:46, Joerg Sonnenberger wrote:
 But, in fact, the case CAN happen if you rename a file to another
that
 happens to be a hardlink to the first.  The rename operations
appears to
The FreeBSD behavior was intentional.  I think this change violates
POSIX, which states:
"If the old argument and the new argument resolve to the same 
existing
file, rename() shall return successfully and perform no other 
action."
I think they mean "file name", not "physical data" (= inode). Like
	mv /usr/src/sys/sys/../Makefile.inc /sys/Makefile.inc
which resolves to the same file (through a .. and a symlink)
Nope, there is one example given in SUS:
     The specification that if old and new refer to the same file is
intended to guarantee that:
rename("x", "x");
     does not remove the file.
I didn't say anything different, I just used a more complex example.  
Point is that I don't see SUSv3 talking about hardlinks ("links") in 
this case.  So I think Matt's change is correct and brings us (again?) 
to POSIX mandated behaviour.

FWIW, Linux and OSX do this:

$ touch foo
$ ln foo bar
$ ls -l
total 0
-rw-r--r--  2 corecode users 0 Aug 15 14:02 bar
-rw-r--r--  2 corecode users 0 Aug 15 14:02 foo
$ mv foo bar
$ ls -l
total 0
-rw-r--r--  1 corecode users 0 Aug 15 14:02 bar
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: pgp00017.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/20050815/a5e2054d/attachment-0022.obj>