[dropping cygwin - this part of my response is specific to upstream coreutils] On 01/09/2012 05:10 PM, Linda Walsh > 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 eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org