Subject: Re: rename(2) behaviour
To: None <email@example.com, firstname.lastname@example.org>
From: Christian Groessler <email@example.com>
Date: 05/16/2003 00:55:46
> der Mouse wrote:
>> In a rename, where the old and the new name are links to the same
>> file, netbsd deletes the old name. Linux does nothing.
>> OTOH, the netbsd man page explicitly states:
>> If both from and to are pathnames of the same existing file in the file
>> system's name space, rename() returns successfully and performs no other
> For what it may be worth, I think NetBSD's behaviour is right and its
> manpage needs fixing. I believe that in general the effect of a
> successful rename(src,dst) should be as if the sequence unlink(dst),
> link(src,dst), unlink(src) had been done, and that this shouldn't be
> affected by whether src and dst started out being hardlinks to the same
> object (file or not).
Yes, I, too, think netbsd's behaviour is more consistent. But I also
tried the operation on some SVR4 variant, and it behaved like
Linux. So there might be some standard which defines what should
> Now, if both src and dst not only refer to the same object but refer to
> it via the same link, which is what I suspect that paragraph was
> intended to cover, _then_ rename() should do nothing. I'm not sure how
> best to phrase this. Perhaps something like the above sequence of
> unlink/link/unlink, with the additional caveat that if the unlink(dst)
> would cause not only dst but also src to vanish, the rename() call
> succeeds without doing anything.
You mean "rename 'name' 'name'" should do nothing?