Date: Tue, 10 Sep 2002 15:35:52 +0200 From: Eivind Eklund <eivind@FreeBSD.org> To: Bruce Evans <bde@zeta.org.au> Cc: 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: <20020910133552.GD86704@phoenix.dmnstech.net> In-Reply-To: <20020910230114.K1753-100000@gamplex.bde.org> References: <20020910124618.GC86704@phoenix.dmnstech.net> <20020910230114.K1753-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 10, 2002 at 11:22:03PM +1000, Bruce Evans wrote:
> On Tue, 10 Sep 2002, Eivind Eklund wrote:
> > On Tue, Sep 10, 2002 at 04:09:13AM -0700, Bruce Evans wrote:
> > > bde 2002/09/10 04:09:13 PDT
> > >
> > > Modified files:
> > > sys/kern vfs_syscalls.c
> > > sys/gnu/ext2fs ext2_vnops.c
> > > sys/ufs/ufs ufs_vnops.c
> > > Log:
> > > vfs_syscalls.c:
> > > Changed rename(2) to follow the letter of the POSIX spec. POSIX
> > > requires rename() to have no effect if its args "resolve to the same
> > > existing file". I think "file" can only reasonably be read as referring
> > > to the inode, although the rationale and "resolve" seem to say that
> > > sameness is at the level of (resolved) directory entries.
> >
> > 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
below (not creating an error for the case where you are actually doing a
complex null rename) seems perfectly reasonable. (I at least know that I
would be astonished if doing a rename depended on what inode a directory entry
pointed at - it is a pure name manipulation...)
> > The POSIX interpretation would seem to prohibit the mv in
> > mkdir d
> > touch d/a
> > ln -s d d2
> > mv d2/a d/a
> > from having any effect, which makes way more sense to me. This also seems to
> > be what the old code did.
>
> Er, this case shouldn't work. I think it didn't. d2/a and d/a are the same
> directory entry here.
Exactly. And when they are, rename() should return OK without doing anything.
Which seems to be what the old code did, from what I can read.
Eivind.
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?20020910133552.GD86704>