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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10468 in the body.
You can then email your comments to 10468 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Linda Walsh , <cygwin <at> tlinx.org>" <coreutils <at> tlinx.org>
To: bug-coreutils <at> gnu.org
Cc: "cygwin <at> cygwin.com" <cygwin <at> cygwin.com>
Subject: BUG: Severe or critical - deletes existing files and leaves nothing.
	(cp)
Date: Mon, 09 Jan 2012 13:19:43 -0800

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...

On unix, I've run a 'dedup' in my font dir, that joined any files that were the
same so they are hard links to each other. (made sense at the time... ;-) ).

windows treats different cased file names as the same.

Along comes cp, on cygwin, .. but I don't think this is a cygwin bug, as
it's doing what it is supposed to do.. it is cp  that is problematic.

Note, in the below, I an alias for cp is in effect:

alias cp='cp --preserve=mode,timestamps'

i.e. by default, I try to preserve 'simple'-permissions, and timestamps.


First I tried:

/usr/share/fonts> cp -avu //bliss/usr_share/fonts/. .


Got:

removed `././Adobe (afm) fonts/Symbol.afm'
cp: cannot create hard link `././Adobe (afm) fonts/Symbol.afm' to `././Adobe 
(afm) fonts/symbol.afm': No such file or directory
removed `././Adobe (afm) fonts/cmr10.afm'
cp: cannot create hard link `././Adobe (afm) fonts/cmr10.afm' to `././Adobe 
(afm) fonts/CMR10.afm': No such file or directory
removed `././Adobe (afm) fonts/cmex10.afm'
(and many more... )

It removes an existing file 'Symbol', because because it sees that 'Symbol' is not
a hard link to 'symbol'; I specified "-a" to make an exact copy, so it's trying 
to copy links.

But by removing 'Symbol', it removes 'symbol' and THEN can't link to it...
thus 'symbol' is gone from the local dir.
---
ok, at this point, I would consider it 'my bad, for using cp on windows (it used 
to work without these issues, not sure what has changed)...


Then I tried the less strict:

> 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...)


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/. .

and...

removed `././Adobe (afm) fonts/cmbx5.afm'
cp: cannot create hard link `././Adobe (afm) fonts/cmbx5.afm' to `././Adobe 
(afm) fonts/CMBX5.afm': No such file or directory
removed `././Adobe (afm) fonts/cmbx7.afm'
cp: cannot create hard link `././Adobe (afm) fonts/cmbx7.afm' to `././Adobe 
(afm) fonts/CMBX7.afm': No such file or directory
removed `././Adobe (afm) fonts/cmmi10.afm'

... *sigh*...
my poor cumberland fonts... so sad!
um.... hey, if it shouldn't have removed them on -rvu, it doubly shouldn't have 
done so on
when I told it "-n" (--no-clobber) don't clobber existing files...



DOUBLE BUG!....

 cygcheck -f /bin/cp
coreutils-8.14-1

Message #12 received at 10468-done <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: "Linda Walsh , <cygwin <at> tlinx.org>" <coreutils <at> tlinx.org>
Cc: "cygwin <at> cygwin.com" <cygwin <at> cygwin.com>, 10468-done <at> debbugs.gnu.org,
	control <at> debbugs.gnu.org
Subject: Re: bug#10468: BUG: Severe or critical - deletes existing files and
	leaves nothing. (cp)
Date: Mon, 09 Jan 2012 14:41:22 -0700

[Message part 1 (text/plain, inline)]

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 <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #13 received at 10468-done <at> debbugs.gnu.org (full text, mbox):

From: "Linda Walsh <cygwin <at> tlinx.org" <coreutils <at> tlinx.org>
To: Eric Blake <eblake <at> redhat.com>
Cc: "cygwin <at> cygwin.com" <cygwin <at> cygwin.com>, 10468-done <at> debbugs.gnu.org,
	control <at> debbugs.gnu.org
Subject: Re: bug#10468: BUG: Severe or critical - deletes existing files and
	leaves nothing. (cp)
Date: Mon, 09 Jan 2012 16:10:05 -0800

Tag EricBlake : a bug

please don't ask that my bugs be closed without looking at what I said.


Eric Blake wrote:
> 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...
>>First I tried:
>>/usr/share/fonts> cp -avu //bliss/usr_share/fonts/. .
>> FAIL
>> ok, at this point, I would consider it 'my bad, for using cp on
>>  windows (it used to work without these issues, not sure what has changed)...
> 
> The problem is not in coreutils, but in your operating system's
> limitations,
---
Can you read?

>>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

>> 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,

Why is it trying to create hard links and deleting files to prepare for this?

I'm aware Windows is case insensitive -- That's not the bug I was
reporting or that you asked closed idjit!

I'm saying I DIDN'T ask it to copy links... so it should simple copied
case variations multiple times to the same target "dumbly" (like it used to).

Now it's "smarter"[sic]. and tries to copy links even when not told
to preserve links.

Can you explain why case insensitivity in the target would cause it
to 'preserve links' when not told to?

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.

But baring that, it looks like 'cp', isnt' doing what it is documented to do --
regardless of case sensitivity.


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?

Message #16 received at 10468-done <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: "Linda Walsh <cygwin <at> tlinx.org" <coreutils <at> tlinx.org>
Cc: control <at> debbugs.gnu.org, 10468-done <at> debbugs.gnu.org
Subject: Re: bug#10468: BUG: Severe or critical - deletes existing files and
	leaves nothing. (cp)
Date: Mon, 09 Jan 2012 17:45:34 -0700

[Message part 1 (text/plain, inline)]

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

On 01/09/2012 05:10 PM, Linda Walsh <cygwin <at> tlinx.org 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   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #19 received at 10468 <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: 10468 <at> debbugs.gnu.org
Cc: Eric Blake <eblake <at> redhat.com>
Subject: Re: bug#10471: Severe or critical - deletes existing files and leaves
	nothing. (cp)
Date: Mon, 09 Jan 2012 16:46:40 -0800

reopen 10468
thanks
=============

You didn't answer my question.. I explained why it was a bug.

You didn't explain why it is copying links.


Don't put it on me to reproduce w/o cygwin... the program's
isn't behaving as documented.

If you think it is the cause of cygwin...
I asked you to explain why.

The fact that there is no behavior in cygwin that would activate forced
link coping doesn't seem to bother you.




Eric Blake wrote:
> forcemerge 10468 10471
> thanks
> 
> On 01/09/2012 05:11 PM, Linda Walsh wrote:
>> Please do not close this bug... EB doesn't know what he is talking
>> about -- he didn't read the bug.
> 
> I did too read your report, but I stand by my position that upstream cp
> is doing the right things for a case-sensitive system,
---
	Whether or not "cp" tries to duplicate links on the local system
has NOTHING to do with case sensitivity...

It is an explicit 'cp' option "--preserve=links" (turned on with
-a or -d -- neither of which I used in the 2nd and 3rd examples)...

Message #24 received at 10468 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: 10468 <at> debbugs.gnu.org
Subject: Re: bug#10471: Severe or critical - deletes existing files and leaves
	nothing. (cp)
Date: Mon, 09 Jan 2012 17:57:58 -0700

[Message part 1 (text/plain, inline)]

On 01/09/2012 05:46 PM, Linda Walsh wrote:
> reopen 10468
> thanks
> =============
> 
> You didn't answer my question.. I explained why it was a bug.

You explained that the cygwin binary for cp didn't meet your
expectations, but I in turn explained that the cygwin cp binary has code
that is not present upstream, and that it is this distro-specific code
which is the primary suspect.  Until we can confirm that upstream
coreutils has the same issue without cygwin in the mix, then the bug
should be discussed on the cygwin list.

> 
> You didn't explain why it is copying links.

That's correct, because I haven't reproduced it on my cygwin machine
yet.  But I also haven't discarded that fact, merely isolated it to the
right place to discuss it.  My replies on that topic will be local to
the cygwin list, unless I can prove that the problem really does affect
upstream cp.

> If you think it is the cause of cygwin...
> I asked you to explain why.

I think I did a fair job of that.  The cygwin pre-built binary contains
additional patches not present in upstream coreutils, as well as
interacting with a rather complex cygwin1.dll that must deal with both
settings of the Windows case-sensitivity registry key, either of which
is more likely to have an issue in corner cases of case sensitivity than
upstream coreutils.

> 
> The fact that there is no behavior in cygwin that would activate forced
> link coping doesn't seem to bother you.

Wrong again - it does bother me, but without further evidence, it only
bothers me concerning the cygwin build, and not coreutils in general.
Until we have evidence to the contrary that upstream coreutils is also
buggy, I'd rather focus on fixing the bug where it was observed - on the
cygwin list.

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

[signature.asc (application/pgp-signature, attachment)]

Message #29 received at 10468-done <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: Eric Blake <eblake <at> redhat.com>
Cc: control <at> debbugs.gnu.org, 10468-done <at> debbugs.gnu.org
Subject: Re: bug#10468: BUG: Severe or critical - deletes existing files and
	leaves nothing. (cp)
Date: Mon, 09 Jan 2012 17:00:40 -0800

Eric Blake wrote:
> [dropping cygwin - this part of my response is specific to upstream
> coreutils]
> 
> On 01/09/2012 05:10 PM, Linda Walsh <cygwin <at> tlinx.org 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?
----
	This is further evidence that you closed the bug before
reading it.

	as:
> type cp
cp is aliased to `cp --preserve=mode,timestamps'

Was listed as being the case BEFORE the first test case...


> 
>>>> 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.

Um.... Quoting from the original bug report:
   "Note, in the below, I an alias for cp is in effect:
    alias cp='cp --preserve=mode,timestamps'"
---
Before the first example.

It DOESN'T say to preserve links. it doesn't say '-f'

>> 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,
----
Yes I am aware... I would make linux case insensitive, if it had the
option.

Examples -- some linux's now find packages and man pages, even if you
don't have the caPitAliZatioN exactly the way someone  thought should be
capitalized.


 and that my suspicion is
> that using Windows in a case-sensitive manner would have avoided your
> problems in the first place.
----
Nope...

just the opposite... pressing 'shift' causes more wear and tear on my
hands... exacerbates RSI -- which has caused nerve damage, causing
my fingers to be less coordinated -- such that it is harder for me to
precisely control the order of how keys are entered -- such as SHIFT and some
letter at the same time.


> 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

---

Um, excuse me, but cp is a gnu util, not part of linux, -- you should
demonstrate that it is not a bug in cygwin, as adding the linux kernel
to the mix, is another piece of software...

If you want your pure test case, go scrape up a working test case on
Hurd, don't be pretending that Linus is GNU...

Message #37 received at 10468 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 10468 <at> debbugs.gnu.org, coreutils <at> tlinx.org
Subject: Re: bug#10468: BUG: Severe or critical - deletes existing files and
	leaves nothing. (cp)
Date: Mon, 09 Jan 2012 17:15:26 -0800

On 01/09/12 17:00, Linda Walsh wrote:
> cp is a gnu util, not part of linux, -- you should
> demonstrate that it is not a bug in cygwin

This is not a practical division of labor.  As a general rule,
we don't have the resources to deal with Windows ports.

I suggest raising this issue with the people who are actually
doing the Windows port, whoever they are.  If it's a
problem with the port, they can fix it themselves without putting
further load on us; if not, they'll have a better chance to diagnose
and fix the problem than we will (our chance is essentially zero).

Message #40 received at 10468 <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>, 10468 <at> debbugs.gnu.org
Subject: Re: bug#10468: BUG: Severe or critical - deletes existing files and
	leaves nothing. (cp)
Date: Mon, 09 Jan 2012 17:41:34 -0800

I see....

So the default policy is that if Windows touches it, gnu won't?

I can see why MS, would be so hostile toward FSF/GNU...

(that's how I feel^, and a bit nastier than I would normally
say, but I'm having a really awful day...(not that you should
care, but... will attempt a more thoughtful response: )

However, I also understand practicalities, of time,

Wouldn't it be appropriate, to keep such a bug at a low priority and in
an unconfirmed state to allow correlation of similar symptoms, should
such come up in the next few-several months (whatever is relevant for
a release).   After such a observation period, if it is still an outlier,
close it as unreproducible or such.


However, simply closing it, as it was seems to more likely indicate it
would likely be ignored in a correlational searches already said to "not be a bug",
due to it coming from 'cygwin'.  Which seems awfully simplistic.

Eric's initial assumptions about the bug were incorrect as I responded.
That doesn't lead me to believe that instantly closing a bug coming
from a cygwin port should always be the best automatic response.

I've been using linux alot longer than cygwin, though cygwin usage
goes back 7-8 years...(linux 12-13), unix longer...





Paul Eggert wrote:
> On 01/09/12 17:00, Linda Walsh wrote:
>> cp is a gnu util, not part of linux, -- you should
>> demonstrate that it is not a bug in cygwin
> 
> This is not a practical division of labor.  As a general rule,
> we don't have the resources to deal with Windows ports.
> 
> I suggest raising this issue with the people who are actually
> doing the Windows port, whoever they are.  If it's a
> problem with the port, they can fix it themselves without putting
> further load on us; if not, they'll have a better chance to diagnose
> and fix the problem than we will (our chance is essentially zero).

Message #43 received at 10468 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 10468 <at> debbugs.gnu.org
Subject: Re: bug#10468: BUG: Severe or critical - deletes existing files and
	leaves nothing. (cp)
Date: Mon, 09 Jan 2012 20:06:27 -0700

[Message part 1 (text/plain, inline)]

[please don't top-post on technical lists]

On 01/09/2012 06:41 PM, Linda Walsh wrote:
> I see....
> 
> So the default policy is that if Windows touches it, gnu won't?

More like: Windows is at best a secondary system, and doesn't have as
high as a priority since it does not promote freedom; you'll get better
response by directing your query to the folks more interested in working
on that platform (and while some of those folks, including me, happen to
hang out on both this list and the cygwin list, I prefer hearing about
cygwin issues on the cygwin list).  We have also seen, time after time,
that bug reports about the windows ports are more often problems with
the port itself and not a problem in the upstream code.  And the
attitude on this list about Windows ports is consistent with the overall
GNU philosophy about ports to highly-crippled proprietary systems:
https://www.gnu.org/software/autoconf/manual/standards.html#References

> Eric's initial assumptions about the bug were incorrect as I responded.

My initial assumptions that the issue has only been seen with cygwin in
the mix, and therefore the cygwin folks should be involved first, is
still correct.  As for whether or not I missed your documentation that
you are using an alias for cp, that is probably the case, but it doesn't
impact the decision that we should deal with the bug at the point where
it was first observed, or that you should simplify your testcase without
cygwin in the mix to prove that it is indeed an upstream issue.

> That doesn't lead me to believe that instantly closing a bug coming
> from a cygwin port should always be the best automatic response.

It's not just cygwin, but all pre-built binaries.  For example, if you
use Fedora, and encounter a crash when using a UTF-8 locale, you are
encouraged to report it to the Fedora folks, who will then triage the
bug and determine if it is a bug in the Fedora multi-byte add-on patch
(which has been the case in a number of circumstances), or generic to
upstream (less common, but it has also happened).  The underlying
principle is the same, though - when dealing with a pre-built binary,
either _report the bug to the person that built the binary_, because the
bug may be in how the binary was built and not upstream, or reproduce
the bug yourself on a self-built coreutils.git, and mention the fact
that you have reproduced it in a pristine upstream environment.  By
removing the variable of the pre-built binary from the equation, you
will have made your bug report that much more reliable, and thrown the
burden of fixing things on the point where the bug has been isolated.

Which means that our behavior of closing bugs that are reported directly
upstream by people that only use a downstream pre-built binary is par
for the course, as we trust the downstream packagers to reopen things if
it turns out to be an upstream issue after all (for this particular bug,
I happen to also be the downstream maintainer, so I _will_ be responding
more on the cygwin side of things, and possibly adding more to this
upstream conversation based on those findings).

Finally, the action of closing a bug does not mean that we are
discouraging all conversation on the topic; it is merely a bookkeeping
practice to make it easier to track which issues are being actively
worked on in the context of this list.  As long as your particular
report is being investigated on the cygwin list, we don't need to be
reproducing the efforts here on this list.  You can reply to closed
bugs, and the replies are still valid.  There's no need to add to the
bookkeeping efforts if a maintainer closed a bug because he thought it
was better dealt with downstream.  And in the future, when I reply to a
cross-posted message (you sent your original to both coreutils and
cygwin), by closing off one side of the cross-posting to focus on the
issue from the other side, I will try to be more clear about making that
particular point clear in my message.

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

[signature.asc (application/pgp-signature, attachment)]

Message #46 received at 10468 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: 10468 <at> debbugs.gnu.org
Subject: Re: bug#10468: BUG: Severe or critical - deletes existing files and
	leaves nothing. (cp)
Date: Mon, 09 Jan 2012 20:16:23 -0800

On 01/09/12 17:41, Linda Walsh wrote:
> Wouldn't it be appropriate, to keep such a bug at a low priority

Perhaps; I don't know.  Its priority is so low here that I'd
rather not spend time thinking about whether it belongs in the
bug database.  For more on the topic of priorities please see
<http://www.gnu.org/prep/standards/html_node/System-Portability.html>.

My suggestion was meant to be a helpful one, in that it proposed
a course of action that's far more likely to get the bug fixed.
Surely that's the main point here.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.