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