On Wed, 2 Apr 2003, Jim Meyering wrote:
> I've just found that many rename implementations
> (all I've checked except that of NetBSD 1.6)
> exhibit surprising behavior, possibly as a result of
> this wording from the specification for rename:
>
> If the old argument and the new argument
> resolve to the same existing file, rename( ) shall return successfully
> and perform no other action.
I changed 2 of them (Linux 10+ years ago, and FreeBSD last year) to
follow the letter of the standard. FreeBSD used to use the same old
BSD implementation as NetBSD.
> But then, in the rationale it says this:
>
> The specification that if old and new refer to the same file is intended
> to guarantee that: rename("x", "x"); does not remove the file.
It's interesting that it still says "file" and not directory entry.
> The ambiguity is when old and new are distinct links to the same inode.
> In that case, I think it makes sense to allow rename to unlink old.
> ----------------
> To see what I mean, try this:
>
> touch a; perl -e 'link "a", "b"; rename "a", "b" or die "$!"'; ls a b
>
> On most systems, you'll see that both `a' and `b' remain.
> On NetBSD, however, rename does what I'd expect and unlinks a.
After thinking about this a lot, I would expect rename() to have
the specified behaviour :-). It gives the nice invariant of never
changing the link count.
> Andries' proposal would allow a rename implementation to
> unlink the file corresponding to the first argument e.g.,
> when old and new correspond to distinct directory entries.
At least the old BSD implementation actually only does this when old
and new correspond to distict directory entries in the same directory.
It also had at least 2 races which could result in removing the file.
So it's not clear that its behaviour was more than a side effect of
a sloppy implementation -- apart from the races, there is no particular
reason why a link in another directory should be more precious than
one in the same directory.
Bruce
|