GNU bug report logs - #62572
cp --no-clobber behavior has changed

Previous Next

Full log

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Michael Stone <mstone <at> debian.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 1058752 <at> bugs.debian.org, Bernhard Voelker <mail <at> bernhard-voelker.de>,
 62572 <at> debbugs.gnu.org
Subject: Re: bug#62572: Bug#1058752: bug#62572: cp --no-clobber behavior has
 changed
Date: Mon, 29 Jan 2024 16:11:05 +0000

On 29/01/2024 14:01, Michael Stone wrote:
> On Sun, Jan 28, 2024 at 11:14:14PM -0800, Paul Eggert wrote:
>> I'm not sure reverting would be best. It would introduce more
>> confusion, and would make coreutils incompatible with FreeBSD again.
> 
> Reverting makes more sense than the current situation. I do not
> understand why you seem to value FreeBSD compatibility more than
> compatibility with the vast majority of installed coreutils/linux
> systems.
> 
>> Yes, it's not a good place to be. Surely current coreutils is better
>> than what Debian is doing.
> 
> You've introduced a silent incompatibility and I'm trying to find some
> way to make that clear. If upstream would provide a better solution I
> would certainly use it. I have despaired of there being such since your
> attitude thus far seems to be entirely dismissive of compatibility
> concerns.

That's a bit unfair.  The current upstream -n behavior is with a view
to being _more_ compat across all systems.
Now I agree this may not be worth it in this case,
but it is a laudable goal.

>> Another possibility is to add a warning that is emitted only at the
>> end of 'cp'. The warning would occur only if the exit code differs
>> because of this cp -n business.
> 
> You'd only emit a notification of a change in behavior if some
> (potentially uncommon/rarely encountered) situation arises which would
> actually trigger breakage? So people can't prepare ahead of time and
> change their script to handle the necessary change in logic, they can
> only maybe figure out why something broke at 2am when the uncommon event
> occurred?

Yes I agree with this point, mostly.
Outputting a diagnostic would help users diagnose what's going on,
and help users to fix forward and avoid their problematic -n usage.
But yes, the crux of the issue with fixing issues as they occur,
is it depends on the state of the destination and so can become an issue
at any time.  Now I previously did an audit with github and debian code search
and noticed very few problematic uses of cp -n, but that does miss
the mountain of private code.

> At the end of the day, -n is basically a useless option with unknowable
> semantics which should be avoided by everyone. In the past it was an
> option which wasn't portable between coreutils/linux and freebsd systems,
> and I guess you've "fixed" that (by making it an option everyone should
> avoid entirely), but let's be honest about how common that concern was.

Right, that's why I'm still leaning towards my proposal in the last mail.
  - revert to previous exit success -n behavior
  - document -n as deprecated
  - provide --update=noclobber to give exit failure functionality
    - BTW, it probably makes sense to print a diagnostic for each skipped file here
      as it's exceptional behavior, for which we're exiting with failure for.
  - the existing --update=none provides the exit success functionality

With the above in place for the next coreutils release,
then debian could remove its noisy patch.

thanks,
Pádraig

Previous Next

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