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