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

Previous Next

To reply to this bug, email your comments to 62572 AT debbugs.gnu.org.

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

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

From: Alberto Salvia Novella <es20490446e <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: cp --no-clobber behavior has changed
Date: Fri, 31 Mar 2023 19:01:09 +0200

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

In the past if you did:
cp --no-clobber $in $out

And "out" existed, "cp" exited with 0. But now, with coreutils 9.2, it
exists with 1.

Is this on purpose?

(When replying include my email in the field "to", as I'm not subscribed to
this list)

[Message part 2 (text/html, inline)]

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

From: Sam James <sam <at> gentoo.org>
To: Alberto Salvia Novella <es20490446e <at> gmail.com>
Cc: bug-coreutils <at> gnu.org, 62572 <at> debbugs.gnu.org,
 Eli Schwartz <eschwartz93 <at> gmail.com>
Subject: Re: bug#62572: cp --no-clobber behavior has changed
Date: Fri, 31 Mar 2023 19:30:47 +0100

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

Alberto Salvia Novella <es20490446e <at> gmail.com> writes:

> In the past if you did:
> cp --no-clobber $in $out
>
> And "out" existed, "cp" exited with 0. But now, with coreutils 9.2, it
> exists with 1.
>
> Is this on purpose?
>
> (When replying include my email in the field "to", as I'm not subscribed to
> this list)

We hit this in Gentoo at https://bugs.gentoo.org/902751. We concluded
the usage in the ebuild ("build script") was wrong, given that the
coreutils-9.2 NEWS says:
> 'cp -n' and 'mv -n' now exit with nonzero status if they skip their
> action because the destination exists, and likewise for 'cp -i',
> 'ln -i', and 'mv -i' when the user declines.  (POSIX specifies
> this for 'cp -i' and 'mv -i'.)

It still was a bit unexpected though given POSIX doesn't specify -n.

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

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Alberto Salvia Novella <es20490446e <at> gmail.com>
Cc: 62572 <at> debbugs.gnu.org
Subject: Re: bug#62572: cp --no-clobber behavior has changed
Date: Fri, 31 Mar 2023 13:01:07 -0700

On 2023-03-31 10:01, Alberto Salvia Novella wrote:
> Is this on purpose?

Yes, part of the idea was to let shell programmers easily test whether 
cp successfully copied the data. Having cp -i conform to POSIX was a 
lesser consideration, though it's a bit nicer if -n and -i are somewhat 
consistent.

For what it's worth, the old behavior wasn't documented and the new 
behavior is.

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

From: Sven Joachim <svenjoac <at> gmx.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Alberto Salvia Novella <es20490446e <at> gmail.com>, 62572 <at> debbugs.gnu.org
Subject: Re: bug#62572: cp --no-clobber behavior has changed
Date: Fri, 31 Mar 2023 22:37:58 +0200

On 2023-03-31 13:01 -0700, Paul Eggert wrote:

> On 2023-03-31 10:01, Alberto Salvia Novella wrote:
>> Is this on purpose?
>
> Yes, part of the idea was to let shell programmers easily test whether
> cp successfully copied the data.

By making them stop using the '-n' option, since they cannot rely on the
exit code anyway?

> Having cp -i conform to POSIX was a
> lesser consideration, though it's a bit nicer if -n and -i are
> somewhat consistent.

It is not so nice that this is probably going to break several dozen
packages in Debian alone. :-(

Cheers,
       Sven

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

From: Alberto Salvia Novella <es20490446e <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 62572 <at> debbugs.gnu.org
Subject: Re: bug#62572: cp --no-clobber behavior has changed
Date: Fri, 31 Mar 2023 22:53:31 +0200

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

https://youtu.be/o_kh1_gOkwk

On Fri, 31 Mar 2023 at 22:01, Paul Eggert <eggert <at> cs.ucla.edu> wrote:

> On 2023-03-31 10:01, Alberto Salvia Novella wrote:
> > Is this on purpose?
>
> Yes, part of the idea was to let shell programmers easily test whether
> cp successfully copied the data. Having cp -i conform to POSIX was a
> lesser consideration, though it's a bit nicer if -n and -i are somewhat
> consistent.
>
> For what it's worth, the old behavior wasn't documented and the new
> behavior is.
>

[Message part 2 (text/html, inline)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Sven Joachim <svenjoac <at> gmx.de>
Cc: Alberto Salvia Novella <es20490446e <at> gmail.com>, 62572 <at> debbugs.gnu.org
Subject: Re: bug#62572: cp --no-clobber behavior has changed
Date: Fri, 31 Mar 2023 14:15:47 -0700

On 2023-03-31 13:37, Sven Joachim wrote:
> On 2023-03-31 13:01 -0700, Paul Eggert wrote:
> 
>> part of the idea was to let shell programmers easily test whether
>> cp successfully copied the data.
> 
> By making them stop using the '-n' option, since they cannot rely on the
> exit code anyway?

Portable code could not rely on the exit status anyway, as FreeBSD cp 
agrees with the new GNU behavior, not the old. See:

https://bugs.gnu.org/61105

It was a messy situation where there was no perfect solution. That being 
said, there is an advantage of consistency with FreeBSD, and the new GNU 
behavior does avoid the race mentioned in Bug#61105.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Sven Joachim <svenjoac <at> gmx.de>
Cc: Alberto Salvia Novella <es20490446e <at> gmail.com>, 62572 <at> debbugs.gnu.org
Subject: Re: bug#62572: cp --no-clobber behavior has changed
Date: Fri, 31 Mar 2023 22:32:12 +0100

On 31/03/2023 22:15, Paul Eggert wrote:
> On 2023-03-31 13:37, Sven Joachim wrote:
>> On 2023-03-31 13:01 -0700, Paul Eggert wrote:
>>
>>> part of the idea was to let shell programmers easily test whether
>>> cp successfully copied the data.
>>
>> By making them stop using the '-n' option, since they cannot rely on the
>> exit code anyway?
> 
> Portable code could not rely on the exit status anyway, as FreeBSD cp
> agrees with the new GNU behavior, not the old. See:
> 
> https://bugs.gnu.org/61105
> 
> It was a messy situation where there was no perfect solution. That being
> said, there is an advantage of consistency with FreeBSD, and the new GNU
> behavior does avoid the race mentioned in Bug#61105.

Perhaps we should support:
  --no-clobber[={skip, fail (default)}]

so then users can at least easily change -n to --no-clobber=skip
to get the old behavior?

An alternative would be to augment the --update option to support:
  --update[={none, older (default)}]
where --update=none would be the equivalent of the old -n behavior.

Perhaps we should also diagnose files skipped in the -n fail case,
to make it easier for users to see what the issue is.

cheers,
Pádraig

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>,
 Sven Joachim <svenjoac <at> gmx.de>
Cc: Alberto Salvia Novella <es20490446e <at> gmail.com>, 62572 <at> debbugs.gnu.org
Subject: Re: bug#62572: cp --no-clobber behavior has changed
Date: Fri, 31 Mar 2023 16:29:03 -0700

On 2023-03-31 14:32, Pádraig Brady wrote:

> Perhaps we should support:
>    --no-clobber[={skip, fail (default)}]
> 
> so then users can at least easily change -n to --no-clobber=skip
> to get the old behavior?
> 
> An alternative would be to augment the --update option to support:
>    --update[={none, older (default)}]
> where --update=none would be the equivalent of the old -n behavior.

The latter sounds a bit better but I suppose either would work. We could 
generalize it a bit further, e.g.:

  --skip-diagnose[={yes,no}]
     Whether to diagnose a copying action being skipped.
  --skip-fail[={yes,no}]
     Whether exit status should be 1 when skipping a copying action.

Presumably similar options would apply to ln and mv.

All these extra options might be overkill, though.


> Perhaps we should also diagnose files skipped in the -n fail case,
> to make it easier for users to see what the issue is.

FreeBSD cp -n doesn't diagnose, and GNU cp -n has never diagnosed, so 
it's probably better to leave sleeping dogs lie.

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

From: Christoph Anton Mitterer <calestyo <at> scientia.org>
To: 62572 <at> debbugs.gnu.org
Subject: Re: cp --no-clobber behavior has changed
Date: Sat, 01 Apr 2023 02:05:15 +0200

In principle I have no strong opinion on what the behaviour should be.

But if one strictly follows the POSIX wording:

>    The following exit values shall be returned:
>     0
>        All input files were [copied/moved] successfully.
>    >0
>        An error occurred.

The change seems to make sense, as one could argue that the above ain't
the case with -n if the destination already exists.

It's however open to debate whether --no-clobber - were it in POSIX -
would have fallen into that spirit.


But at least as of corutils 9.1 's cp info page it was documented as:
>An exit status of zero indicates success, and a nonzero value
>indicates failure.

together with:

> ‘-n’
> ‘--no-clobber’
>     Do not overwrite an existing file; silently do nothing instead.
>     This option overrides a previous ‘-i’ option.  This option is
>     mutually exclusive with ‘-b’ or ‘--backup’ option.

that doesn't seem like failure to me.

So it kinda breaks the "promise" made by the documentation.


I like Pádraig's idea in message #26... but no idea whether it should
be more POSIX like (thus non-zero when nothing was copied) or more
backwards compatible.


Cheers,
Chris.

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

From: Alberto Salvia Novella <es20490446e <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Pádraig Brady <P <at> draigbrady.com>,
 Sven Joachim <svenjoac <at> gmx.de>, 62572 <at> debbugs.gnu.org
Subject: Re: bug#62572: cp --no-clobber behavior has changed
Date: Sat, 1 Apr 2023 03:36:48 +0200

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

I get the impression that right now --no-clover is optimized for the less
common scenarios, while making it less useful for the common ones.

Also --update isn't a substitute of --no-clover. As --no-clover is for
copying when the file is missing, not when it isn't updated.

For example imagine that I have a config template, and a script copies the
template only if it is missing using --no-clover.

If I did the same with --update it could happen the following: the package
that provides the template updates, then --update will override the config
even if it exists, just because the source file is now newer. No good.

So right now the only option that I have is to avoid both --no-clover and
--update all together, and to test for the file existence separately. So
totally useless.

On Sat, 1 Apr 2023 at 01:29, Paul Eggert <eggert <at> cs.ucla.edu> wrote:

> On 2023-03-31 14:32, Pádraig Brady wrote:
>
> > Perhaps we should support:
> >    --no-clobber[={skip, fail (default)}]
> >
> > so then users can at least easily change -n to --no-clobber=skip
> > to get the old behavior?
> >
> > An alternative would be to augment the --update option to support:
> >    --update[={none, older (default)}]
> > where --update=none would be the equivalent of the old -n behavior.
>
> The latter sounds a bit better but I suppose either would work. We could
> generalize it a bit further, e.g.:
>
>    --skip-diagnose[={yes,no}]
>       Whether to diagnose a copying action being skipped.
>    --skip-fail[={yes,no}]
>       Whether exit status should be 1 when skipping a copying action.
>
> Presumably similar options would apply to ln and mv.
>
> All these extra options might be overkill, though.
>
>
> > Perhaps we should also diagnose files skipped in the -n fail case,
> > to make it easier for users to see what the issue is.
>
> FreeBSD cp -n doesn't diagnose, and GNU cp -n has never diagnosed, so
> it's probably better to leave sleeping dogs lie.
>

[Message part 2 (text/html, inline)]

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

From: Alberto Salvia Novella <es20490446e <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Pádraig Brady <P <at> draigbrady.com>,
 Sven Joachim <svenjoac <at> gmx.de>, 62572 <at> debbugs.gnu.org
Subject: Re: bug#62572: cp --no-clobber behavior has changed
Date: Sat, 1 Apr 2023 03:41:10 +0200

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

Or use:
cp --no-clover $in $out || true

But again, surprising behavior. Just a new special case to memorize.

On Sat, 1 Apr 2023 at 03:36, Alberto Salvia Novella <es20490446e <at> gmail.com>
wrote:

> I get the impression that right now --no-clover is optimized for the less
> common scenarios, while making it less useful for the common ones.
>
> Also --update isn't a substitute of --no-clover. As --no-clover is for
> copying when the file is missing, not when it isn't updated.
>
> For example imagine that I have a config template, and a script copies the
> template only if it is missing using --no-clover.
>
> If I did the same with --update it could happen the following: the package
> that provides the template updates, then --update will override the config
> even if it exists, just because the source file is now newer. No good.
>
> So right now the only option that I have is to avoid both --no-clover and
> --update all together, and to test for the file existence separately. So
> totally useless.
>
> On Sat, 1 Apr 2023 at 01:29, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
>
>> On 2023-03-31 14:32, Pádraig Brady wrote:
>>
>> > Perhaps we should support:
>> >    --no-clobber[={skip, fail (default)}]
>> >
>> > so then users can at least easily change -n to --no-clobber=skip
>> > to get the old behavior?
>> >
>> > An alternative would be to augment the --update option to support:
>> >    --update[={none, older (default)}]
>> > where --update=none would be the equivalent of the old -n behavior.
>>
>> The latter sounds a bit better but I suppose either would work. We could
>> generalize it a bit further, e.g.:
>>
>>    --skip-diagnose[={yes,no}]
>>       Whether to diagnose a copying action being skipped.
>>    --skip-fail[={yes,no}]
>>       Whether exit status should be 1 when skipping a copying action.
>>
>> Presumably similar options would apply to ln and mv.
>>
>> All these extra options might be overkill, though.
>>
>>
>> > Perhaps we should also diagnose files skipped in the -n fail case,
>> > to make it easier for users to see what the issue is.
>>
>> FreeBSD cp -n doesn't diagnose, and GNU cp -n has never diagnosed, so
>> it's probably better to leave sleeping dogs lie.
>>
>

[Message part 2 (text/html, inline)]

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

From: Alberto Salvia Novella <es20490446e <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Pádraig Brady <P <at> draigbrady.com>,
 Sven Joachim <svenjoac <at> gmx.de>, 62572 <at> debbugs.gnu.org
Subject: Re: bug#62572: cp --no-clobber behavior has changed
Date: Sat, 1 Apr 2023 16:46:55 +0200

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

Also there's now a bigger problem: that you cannot tell when the copy
failed because the file exists, or because any other reason.

People will just use:
cp --no-clover $in $out || true

But if it fails for any other reason, cross your fingers.

Hence now the option, in practice, is useless. Nobody should be using it.


On Sat, 1 Apr 2023 at 03:41, Alberto Salvia Novella <es20490446e <at> gmail.com>
wrote:

> Or use:
> cp --no-clover $in $out || true
>
> But again, surprising behavior. Just a new special case to memorize.
>
> On Sat, 1 Apr 2023 at 03:36, Alberto Salvia Novella <es20490446e <at> gmail.com>
> wrote:
>
>> I get the impression that right now --no-clover is optimized for the less
>> common scenarios, while making it less useful for the common ones.
>>
>> Also --update isn't a substitute of --no-clover. As --no-clover is for
>> copying when the file is missing, not when it isn't updated.
>>
>> For example imagine that I have a config template, and a script copies
>> the template only if it is missing using --no-clover.
>>
>> If I did the same with --update it could happen the following: the
>> package that provides the template updates, then --update will override the
>> config even if it exists, just because the source file is now newer. No
>> good.
>>
>> So right now the only option that I have is to avoid both --no-clover and
>> --update all together, and to test for the file existence separately. So
>> totally useless.
>>
>> On Sat, 1 Apr 2023 at 01:29, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
>>
>>> On 2023-03-31 14:32, Pádraig Brady wrote:
>>>
>>> > Perhaps we should support:
>>> >    --no-clobber[={skip, fail (default)}]
>>> >
>>> > so then users can at least easily change -n to --no-clobber=skip
>>> > to get the old behavior?
>>> >
>>> > An alternative would be to augment the --update option to support:
>>> >    --update[={none, older (default)}]
>>> > where --update=none would be the equivalent of the old -n behavior.
>>>
>>> The latter sounds a bit better but I suppose either would work. We could
>>> generalize it a bit further, e.g.:
>>>
>>>    --skip-diagnose[={yes,no}]
>>>       Whether to diagnose a copying action being skipped.
>>>    --skip-fail[={yes,no}]
>>>       Whether exit status should be 1 when skipping a copying action.
>>>
>>> Presumably similar options would apply to ln and mv.
>>>
>>> All these extra options might be overkill, though.
>>>
>>>
>>> > Perhaps we should also diagnose files skipped in the -n fail case,
>>> > to make it easier for users to see what the issue is.
>>>
>>> FreeBSD cp -n doesn't diagnose, and GNU cp -n has never diagnosed, so
>>> it's probably better to leave sleeping dogs lie.
>>>
>>

[Message part 2 (text/html, inline)]

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Alberto Salvia Novella <es20490446e <at> gmail.com>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Sven Joachim <svenjoac <at> gmx.de>, 62572 <at> debbugs.gnu.org
Subject: Re: bug#62572: cp --no-clobber behavior has changed
Date: Sat, 1 Apr 2023 16:43:23 +0100

On 01/04/2023 15:46, Alberto Salvia Novella wrote:
> Also there's now a bigger problem: that you cannot tell when the copy
> failed because the file exists, or because any other reason.
> 
> People will just use:
> cp --no-clover $in $out || true
> 
> But if it fails for any other reason, cross your fingers.
> 
> Hence now the option, in practice, is useless. Nobody should be using it.

Well the current thinking is -n is useful to fail with unexpected existing files.

For the functionality you want of only updating non existent files,
one should use the proposed --update=none new option.

It's worth mentioning that this being a new option
impacts the portability of scripts that use it.

cheers,
Pádraig

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Sven Joachim <svenjoac <at> gmx.de>
Cc: Alberto Salvia Novella <es20490446e <at> gmail.com>, 62572 <at> debbugs.gnu.org
Subject: Re: bug#62572: cp --no-clobber behavior has changed
Date: Sat, 1 Apr 2023 16:44:37 +0100

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

On 01/04/2023 00:29, Paul Eggert wrote:
> On 2023-03-31 14:32, Pádraig Brady wrote:
> 
>> Perhaps we should support:
>>     --no-clobber[={skip, fail (default)}]
>>
>> so then users can at least easily change -n to --no-clobber=skip
>> to get the old behavior?
>>
>> An alternative would be to augment the --update option to support:
>>     --update[={none, older (default)}]
>> where --update=none would be the equivalent of the old -n behavior.
> 
> The latter sounds a bit better but I suppose either would work. We could
> generalize it a bit further, e.g.:
> 
>     --skip-diagnose[={yes,no}]
>        Whether to diagnose a copying action being skipped.
>     --skip-fail[={yes,no}]
>        Whether exit status should be 1 when skipping a copying action.
> 
> Presumably similar options would apply to ln and mv.
> 
> All these extra options might be overkill, though.
> 
> 
>> Perhaps we should also diagnose files skipped in the -n fail case,
>> to make it easier for users to see what the issue is.
> 
> FreeBSD cp -n doesn't diagnose, and GNU cp -n has never diagnosed, so
> it's probably better to leave sleeping dogs lie.

OK first stab at --update=none support is attached.

cheers,
Pádraig

[copy--update-none-patch (text/plain, attachment)]

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

From: Alberto Salvia Novella <es20490446e <at> gmail.com>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, Sven Joachim <svenjoac <at> gmx.de>,
 62572 <at> debbugs.gnu.org
Subject: Re: bug#62572: cp --no-clobber behavior has changed
Date: Sat, 1 Apr 2023 20:14:07 +0200

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

Maybe simpler:

-m --missing
Only copy non existing files.

On Sat, 1 Apr 2023 at 17:44, Pádraig Brady <P <at> draigbrady.com> wrote:

> On 01/04/2023 00:29, Paul Eggert wrote:
> > On 2023-03-31 14:32, Pádraig Brady wrote:
> >
> >> Perhaps we should support:
> >>     --no-clobber[={skip, fail (default)}]
> >>
> >> so then users can at least easily change -n to --no-clobber=skip
> >> to get the old behavior?
> >>
> >> An alternative would be to augment the --update option to support:
> >>     --update[={none, older (default)}]
> >> where --update=none would be the equivalent of the old -n behavior.
> >
> > The latter sounds a bit better but I suppose either would work. We could
> > generalize it a bit further, e.g.:
> >
> >     --skip-diagnose[={yes,no}]
> >        Whether to diagnose a copying action being skipped.
> >     --skip-fail[={yes,no}]
> >        Whether exit status should be 1 when skipping a copying action.
> >
> > Presumably similar options would apply to ln and mv.
> >
> > All these extra options might be overkill, though.
> >
> >
> >> Perhaps we should also diagnose files skipped in the -n fail case,
> >> to make it easier for users to see what the issue is.
> >
> > FreeBSD cp -n doesn't diagnose, and GNU cp -n has never diagnosed, so
> > it's probably better to leave sleeping dogs lie.
>
> OK first stab at --update=none support is attached.
>
> cheers,
> Pádraig
>

[Message part 2 (text/html, inline)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>,
 Sven Joachim <svenjoac <at> gmx.de>
Cc: Alberto Salvia Novella <es20490446e <at> gmail.com>, 62572 <at> debbugs.gnu.org
Subject: Re: bug#62572: cp --no-clobber behavior has changed
Date: Sat, 1 Apr 2023 15:44:53 -0700

On 2023-04-01 08:44, Pádraig Brady wrote:

> OK first stab at --update=none support is attached.

Thanks, some comments:


> +  /* Always Overwrite.  */
> +  UPDATE_OVERWRITE,

Might be better to call this UPDATE_ALL as it doesn't overwrite if you 
use cp -l or -s or (in some cases) --preserve=links.

> +static char const *const update_type_string[] =
> +{
> +  "none", "older", NULL
> +};

Perhaps there should also be an --update=all, which is the same as no 
update option at all? It would presumably override previous --update 
suboptions.

>    -n, --no-clobber             do not overwrite an existing file (overrides\n\
> -                                 a previous -i option)\n\
> +                                 a -u or previous -i option)\n\

Shouldn't -n override only previous -u or --update options? I thought 
these options were processed left to right, with later overriding earlier.


> +  -u                           only update when the SOURCE file is newer\n\
>                                   than the destination file or when the\n\
>                                   destination file is missing\n\
> +  --update[=UPDATE_MODE]       like -u, but support skipping existing files;\n\
> +                                 UPDATE_MODE={none,older(default)}\n\

This might be clearer if we describe --update first, and then say that 
-u is equivalent to plain --update.


> +  if (make_backups && x.interactive == I_ALWAYS_SKIP)
> +    {
> +      error (0, 0,
> +             _("options --backup and --update=none are mutually exclusive"));
> +      usage (EXIT_FAILURE);
> +    }

Why is this needed? --backup and -u are not mutually exclusive now. 
Admittedly --backup is useless when -u is given, but it seems a bit 
harsh to error out.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Sven Joachim <svenjoac <at> gmx.de>
Cc: Alberto Salvia Novella <es20490446e <at> gmail.com>, 62572 <at> debbugs.gnu.org
Subject: Re: bug#62572: cp --no-clobber behavior has changed
Date: Sun, 2 Apr 2023 11:10:19 +0100

On 01/04/2023 23:44, Paul Eggert wrote:
> On 2023-04-01 08:44, Pádraig Brady wrote:
> 
>> OK first stab at --update=none support is attached.
> 
> Thanks, some comments:
> 
> 
>> +  /* Always Overwrite.  */
>> +  UPDATE_OVERWRITE,
> 
> Might be better to call this UPDATE_ALL as it doesn't overwrite if you
> use cp -l or -s or (in some cases) --preserve=links.

+1

>> +static char const *const update_type_string[] =
>> +{
>> +  "none", "older", NULL
>> +};
> 
> Perhaps there should also be an --update=all, which is the same as no
> update option at all? It would presumably override previous --update
> suboptions.

+1

>>     -n, --no-clobber             do not overwrite an existing file (overrides\n\
>> -                                 a previous -i option)\n\
>> +                                 a -u or previous -i option)\n\
> 
> Shouldn't -n override only previous -u or --update options? I thought
> these options were processed left to right, with later overriding earlier.


Well I was just keeping the existing global treatment of -n wrt -u, as per:
https://github.com/coreutils/coreutils/commit/7e244891b
-n does seem like more of a global "make sure you don't overwrite anything" setting
(which is analogous to the shell "noclobber" option BTW which also induces a failure when triggered).
I'll think a bit more about this.

>> +  -u                           only update when the SOURCE file is newer\n\
>>                                    than the destination file or when the\n\
>>                                    destination file is missing\n\
>> +  --update[=UPDATE_MODE]       like -u, but support skipping existing files;\n\
>> +                                 UPDATE_MODE={none,older(default)}\n\
> 
> This might be clearer if we describe --update first, and then say that
> -u is equivalent to plain --update.

+1

>> +  if (make_backups && x.interactive == I_ALWAYS_SKIP)
>> +    {
>> +      error (0, 0,
>> +             _("options --backup and --update=none are mutually exclusive"));
>> +      usage (EXIT_FAILURE);
>> +    }
> 
> Why is this needed? --backup and -u are not mutually exclusive now.
> Admittedly --backup is useless when -u is given, but it seems a bit
> harsh to error out.

Yes --backup is redundant with -n or --update=none.
We already disallowed --backup with -n,
so I was just being consistent with disallowing --backup with --update=none.
I'll remove this new restriction.

thanks for the review,
Pádraig

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Sven Joachim <svenjoac <at> gmx.de>
Cc: Alberto Salvia Novella <es20490446e <at> gmail.com>, 62572 <at> debbugs.gnu.org
Subject: Re: bug#62572: cp --no-clobber behavior has changed
Date: Thu, 6 Apr 2023 15:50:08 +0100

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

Take 2 attached.

cheers,
Pádraig

[copy--update-none-patch (text/plain, attachment)]

Previous Next

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