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

Previous Next

Package: coreutils;

Reported by: Alberto Salvia Novella <es20490446e <at> gmail.com>

Date: Fri, 31 Mar 2023 17:49:01 UTC

Severity: normal

Full log


View this message in rfc822 format

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: 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)]

This bug report was last modified 1 year and 176 days ago.

Previous Next


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