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.
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.
Andries Brouwer already noticed the ambiguity and filed this, back in 1999:
http://www.opengroup.org/austin/mailarchives/austin-review-l/msg00048.html
I did not find a follow-up to that message. Was there one?
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.
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.
|