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

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

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
Description: This is a digitally signed message part