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.
