Re: bug#10468: BUG: Severe or critical - deletes existing files and leaves nothing. (cp)

[Eric Blake <eblake at redhat dot com>]

tag 10468 notabug
thanks

On 01/09/2012 02:19 PM, Linda Walsh , <cygwin AT tlinx.org> wrote:
> 
> 
> I was trying to copy a font dir from a unix to a windows machine.
> 
> Problem is there are duplicates -- where only the case differs...

The problem is not in coreutils, but in your operating system's
limitations, and in your configuration.  Windows (and thus Cygwin) can
be put in a mode where it preserves case (and I highly recommend doing
so if you want your example to work):
http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive

Without that setting, there is nothing that coreutils can do on your
behalf: the default case-insensitive behavior of Windows violates POSIX,
and forcing coreutils to add bloat to work around this violation is
rather difficult and unpalatable compared to all other operating systems
that already follow POSIX.  So I am closing the upstream coreutils bug
report.

There may be a way to make the cygwin port of coreutils smarter about
case-sensitive issues when the Windows setting is case-insensitive, but
it would be specific to the cygwin port.  Meanwhile, I'm not convinced
it is worth slowing down the common case by checking for case clash on
all operations, since most users that either avoid case clash or have
the registry setting on, just to help out the rare case of a user that
has case clash but the registry setting off.  You are more than welcome
to discuss this further on the cygwin list, and preferably provide
patches if you want behavior changed, but again, that would most likely
be cygwin-specific and does not need to involve the upstream coreutils
list (the cygwin port of coreutils already carries several other patches
for dealing with non-POSIX issues that don't need to be ported back
upstream, such as how to handle .exe suffixes).

>> cp -rvu /usr/share/fonts> cp -rvu //bliss/usr_share/fonts/. .
> 
> figuring without the "-a" it wouldn't try to force linking, thus no
> prob... ... well...
> removed `././OTF/AJensonPro-Bold.otf'
> cp: cannot create hard link `././OTF/AJensonPro-Bold.otf' to
> `././OTF/ajensonpro-bold.otf': No such file or directory
> removed `././OTF/AJensonPro-BoldCapt.otf'
> cp: cannot create hard link `././OTF/AJensonPro-BoldCapt.otf' to
> `././OTF/ajensonpro-boldcapt.otf': No such file or directory
> removed `././OTF/AJensonPro-BoldDisp.otf'
> ------
> ?!!?!   Why is it trying to create hard links again?  I didn't specify
> preserve links!?!
> (i.e. this is a cp BUG...)

If I understand correctly, your problem stems from the fact that your
source location has multiple hard links to the same file but with
different case, while your destination can't support two hard links to
the same file differing only in case, so there is no sane way to say
which of the two spellings should be copied.  It's not cp's fault that
you are copying from a permissive system to a restrictive one; and while
the errors may not be the most friendly, at least they are accurate.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature