New rename(2) function

Eric Blake
Thu Aug 9 09:15:00 GMT 2007

Eric Blake <ebb9 <at>> writes:

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

Looks like this part works in the latest snapshot.  Thanks for the 

However, there is still a bug:

$ mkdir d1 d2
$ touch d1/f
$ mv -T d1 d2 # forces the call of rename("d1", "d2"), in coreutils 6.0+
mv: cannot move `d1' to `d2': Permission denied

oops - on Linux, this correctly removes the empty directory d2, then renames d1 
to d2, so that you now have d2/f.

(Here's an example of a similar sequence that triggers the rename of a non-
empty directory to overwrite an existing empty directory; this sequence is 
tested on Solaris, so it doesn't rely on non-POSIX -T, nor does it trip the mv -
T bug present in coreutils prior to 6.0:
# mkdir -p a b/a
# touch a/f
# /bin/mv a b
# ls b/a/f

Also, the SUSv3 check could use one more slight optimization - the check for 
whether the old file has more than one hardlink is more likely to trigger for 
directories than files (hard links aren't that common for files, but all 
directories have multiple links); but since Windows (and thus cygwin) does not 
allow directories to be hardlinked, you might as well skip querying the file id 
if the old path was a directory.

Eric Blake

Unsubscribe info:
Problem reports:

More information about the Cygwin-developers mailing list