Subject: Re: rename(2) behaviour
To: None <,>
From: Christian Groessler <>
List: tech-toolchain
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
>>      action.

> 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?
Probably :-)