Date: Tue, 10 Sep 2002 11:55:56 -0700 (PDT) From: Archie Cobbs <archie@dellroad.org> To: Eivind Eklund <eivind@FreeBSD.org> Cc: Bruce Evans <bde@zeta.org.au>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern vfs_syscalls.c src/sys/gnu/ext2fs ext2_vnops.c src/sys/ufs/ufs ufs_vnops.c Message-ID: <200209101855.g8AItuf34207@arch20m.dellroad.org> In-Reply-To: <20020910133552.GD86704@phoenix.dmnstech.net> "from Eivind Eklund at Sep 10, 2002 03:35:52 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Eivind Eklund writes:
> > > This seems to be wrong semantics to me - as far as I can tell, you've just
> > > made the mv in the following case pass through without any change:
> > > touch a
> > > ln a b
> > > mv a b
> > > ... which would normally result in you just having the link 'b' to the file
> > > originally named 'a', but you are silently leaving 'a' and 'b'.
> >
> > Yes, POSIX seems to require leaving 'a' alone here. I used essentially this
> > to test recent changes.
>
> I looked the SUSv3 wording (which should be the same), and found it somewhat
> unclear. I believe the intent is to refer to 'file' as in 'directory entry'
> (after resolution of symbolic links). The sentence in question ("If the old
> argument and the new argument resolve to the same existing file, rename()
> shall return successfully and perform no other action.") is in the section
> discussing symbolic links, and I believe that to be what it refers to.
>
> The new behaviour is IMO in violation of POLA, while the behaviour described
I agree completely... it offends my sense of POLA to have 'mv a b' not
remove the directory entry for 'a', even if 'a' and 'b' are hardlinked.
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200209101855.g8AItuf34207>