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

From: Eric Blake <[email-masked]>
Date: Mon, 09 Jan 2012 17:45:34 -0700

[dropping cygwin - this part of my response is specific to upstream
coreutils]

On 01/09/2012 05:10 PM, Linda Walsh <[email-masked] wrote:
>> The problem is not in coreutils, but in your operating system's
>> limitations,
> ---
> Can you read?

Yes, which is why I wrote the reply that I did, after reading your full
mail.  I was not outright dismissing your bug report, I was just merely
closing the upstream coreutils instance of it, and trying to redirect
the conversation to a more appropriate location (the cygwin mail for
your bug report is still very much open, and I hope to reply more on
that thread).  I'm not trying to insult you, although I can see how my
mail may have come across in that manner, so I apologize if that has
happened.  But please, return the favor and give me the benefit of a
doubt as well, rather than escalating this into a battle of name-calling.

> 
>>> Then I tried the less strict:
>>> cp -rvu /usr/share/fonts> cp -rvu //bliss/usr_share/fonts/. . ALSO
>>> FAILED, trying to copy links
> ---
> 
> How is it that it copying the links is not a bug?
> 
> I didn't ASK IT to preserve-links

Are you sure you don't have a shell alias or function for cp that is
adding options you did not type on the command line?  What does 'type
cp' output for you?

>>> Well if I could just get it to copy them and not try to link them...
>>> so it copies them twice..at least they get here...
>                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> so I try the only thing that might not remove files "n":
>>> cp -nrvu //bliss/usr_share/fonts/. .
>>> FAIL
> ===
> again, not only did I NOT say preserve links, BUT I asked it not
> to clobber files (-n), so again,

Your behavior sounds an awful lot like you have an alias which is
including other options, perhaps -f, in what is actually being passed to
cp, compounded by the fact that creating a file by one spelling makes it
appear as if the other spelling is already present.

> I'm aware Windows is case insensitive

That's not quite what I said - I said that Windows can be configured to
be case-sensitive, and that when you have a situation with case clashes,
you may be better off turning that configuration bit before reporting a
bug.  And since it is not the default for Windows, I'm not sure if you
are aware that Windows can be case sensitive, and that my suspicion is
that using Windows in a case-sensitive manner would have avoided your
problems in the first place.

> If there is a bug in the cygwin code that forces link copying, always,
> then I can see that this bug isn't in the 'cp' code, but in code you aren't
> mentioning.

There very well could be a bug in the cygwin port of coreutils, such
that cygwin's cp is implying --preserve=all when it shouldn't be, but
again, such matters should be raised on the cygwin list, not here.

> Also, XFS has a 'case-insensitive' option as well.
> 
> You may ask that Windows not be a reason for adding bloat to cp,
> but what about a core linux FS?

And as I said in another mail, if you can demonstrate this problem with
upstream coreutils on a Linux kernel and XFS file system, with cygwin
completely removed from the mix, then we will definitely reopen this
bug, as that will be proof that it is a problem in the upstream cp and
not in the cygwin port of cp.  But for now, you still haven't managed to
convince me that the bug appears anywhere but in the cygwin port,
meaning that cygwin is the better place to come to a full understanding
of the problem and any possible solutions.

-- 
Eric Blake   [email-masked]    +1-919-301-3266
Libvirt virtualization library http://libvirt.org