Bruce Evans wrote:
> On Wed, 2 Apr 2003, Jim Meyering wrote:
...
>> 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.
Hi Bruce,
Starting in an empty directory, then with this set-up,
touch a; ln a b
would you really expect `rename ("a", "b")' to do nothing and return zero?
Would you also expect `mv a b' to do nothing and exit successfully?
If so, would you please explain why that makes sense, other than from
the invariant link count standpoint?
If you can justify the above, maybe I can use the same argument
to justify changing GNU mv back so that `mv a b' silently does nothing.
In coreutils-5.0, it silently does nothing, but I'm convinced that that
is wrong, so I've already made the change to have it unlink `a',
regardless of how rename happens to work.
>> 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.
FYI, at least the rename of NetBSD 1.6 is implemented so that
rename *does* unlink OLD, even when OLD and NEW are in different
directories. So this behavior may well be the result of a deliberate
design decision.
$ >a; mkdir d; ln a d/b; perl -e 'rename "a", "d/b" or die "$!"'; find .
.
./d
./d/b
Jim
|