In article <200305152219.SAA03246@Sparkle.Rodents.Montreal.QC.CA> you write:
>> 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).
>
>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 _think_ that's what the "in the file system's name space" is meant to
mean.  If so, I'd phrase it as "pathnames referring to the same directory
entry".

On the other hand, POSIX has similar wording, but without "in the file
system's name space":

# If the <old> argument and the <new> argument resolve to the same existing
# file, rename() shall return successfully and perform no other action.

This was raised as a defect in POSIX in 1999[1], but it foundered in the
bickering over the right form of words.  It was brought up again recently,
but I don't think an actual aardvark has come of it.

[1] <http://www.opengroup.org/austin/mailarchives/austin-review-l/msg00048.html>

I'm about to go to bed, so I can't file an aardvark now.  I'll try to
remember to do so tomorrow.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/acorn26           <URL:http://www.netbsd.org/Ports/acorn26/>