This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New rename(2) function

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:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]