Subject: bug#62572: cp --no-clobber behavior has changed

From: Alberto Salvia Novella <[email-masked]>
Date: Sat, 1 Apr 2023 16:46:55 +0200

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 <[email-masked]>
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 <[email-masked]>
> 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 <[email-masked]> 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.
>>>
>>