bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alberto Salvia Novella
Subject: bug#62572: cp --no-clobber behavior has changed
Date: Sat, 1 Apr 2023 03:36:48 +0200

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]