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

[Michael Stone]

On Fri, Dec 15, 2023 at 11:21:06AM -0800, Paul Eggert wrote:
> Stlll, Pádraig gave a reasonable summary of why the change was made, 
> despite its incompatibility with previous behavior. (One thing I'd add 
> is that the FreeBSD behavior is inherently less race-prone.) It seemed 
> like a good idea at the time all things considered, and to my mind 
> still does.

I think you underestimate the value of maintaining compatibity with 
deployed versions. In the abstract it may have been a nice cleanup, but 
there are a lot of dumb things in the posix utilities that have been 
dumb for so long it's not worth the pain of changing them. Since this 
change hasn't yet hit mainstream debian, ubuntu, rhel, or suse users, I 
strongly suspect that this is a case where the absence of complaints is 
simply a sign that most of the people who'd be impacted haven't 
experienced the change yet.

> Even if we tell people not to use -n at all, that doesn't mean we 
> should revert to the coreutils 9.1 behavior.

It does, IMO, as it would be less likely to break scripts written by 
existing coreutils users.

> The cat is to some extent out of the bag. Unless one insists on 
> (FreeBSD | coreutils 9.2-9.4), or insist on coreutils 7.1-9.1, one 
> should not rely on cp -n failing or silently succeeding when the 
> destination already exists. This will remain true regardless of 
> whether coreutils reverts to its 7.1-9.1 behavior.

Or you use a distribution that has to patch to maintain compatibility 
between versions. Ideally upstream would revert the behavior for now, 
deprecate as the long term fix, and all distributions would work the 
same. The other option is that each distribution decides whether to be 
compatible with upstream coreutils or their own previous release.