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

[Dominique Martinet]

Paul Eggert wrote on Fri, Dec 15, 2023 at 11:21:06AM -0800:
> 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.

This. Scripts that want to be portable already can't assume cp -n will
do what they want, so at this point it doesn't really matter what
coreutils does in the grand scheme of things.

For distros like debian since even -testing hasn't seen coreutils 9.2,
there's still value in reverting locally (with a warning that it's not
reliable perhaps?), but in general coreutils 9.2 has been out for 9
months (2023 March 20), so many systems can already be considered
affected; but it's a disservice to users to just try to hide the problem
under the rug.


(To give a data point, this did bite us as well, and I was annoyed
enough that I went to look for the old bug report back in September, but
at that point 9.3 had already been out and I had given up without
reporting anything as nothing would change the fact that my scripts
would need updating. For the gory details I also need compatibility
with busybox cp (where -n silently ignores existing files), so
--update=none is not an option, but I for this particular usage I
settled for '-u' (--update=older, that busybox also support as short
option only...), and I since hurried to forget about it)

-- 
Dominique Martinet | Asmadeus