New rename(2) function

Christian Franke Christian.Franke@t-online.de
Fri Aug 10 20:37:00 GMT 2007


Corinna Vinschen wrote:
> On Aug  9 21:23, Eric Blake wrote:
>   
>> According to Christian Franke on 8/9/2007 10:38 AM:
>>     
>> ...
>>     
>
> Btw., this looks weird in mv:
>
>   $ mv -T Bar bar
>   mv: cannot remove `Bar': Operation not permitted
>
> Huh?  Nobody asked for removing Bar, afaics...
>
>   

The root of the problem is IMO the copy.c:same_file_ok() function, see 
attached code snippets (coreutils 6.9).

On -T, it treats the dest dir as a file and checks (1 < #links) which is 
always true for a directory. The same_name() function is case sensitive.

Therefore, same_file_ok() returns true and sets unlink_src=true.

Later, copy_internal() handles the source path as a hard link to 
destination and tries to unlink() the source. Fortunately, unlink() is 
unable to rmdir().

No problem if both names match:

$ mv -T bar bar
mv: `bar' and `bar' are the same file

$ mv -T ./BAR BAR
mv: `./BAR' and `BAR' are the same file


In the file case, the problem does not occur because #links usually are 1:

$ touch Foo

$ mv Foo foo
mv: `Foo' and `foo' are the same file


But be aware: If there are hard links, things get really worse:

$ touch Foo

$ ln Foo Fool

$ mv -v Foo foo
removed `Foo'

$ ls foo* Foo*
ls: cannot access foo*: No such file or directory
Fool


This is probably not POSIX compliant ;-)

Christian

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: copy.c.txt
URL: <http://cygwin.com/pipermail/cygwin-developers/attachments/20070810/7c070b91/attachment.txt>


More information about the Cygwin-developers mailing list