GNU bug report logs - #62572
cp --no-clobber behavior has changed

Previous Next

Package: coreutils;

Reported by: Alberto Salvia Novella <es20490446e <at> gmail.com>

Date: Fri, 31 Mar 2023 17:49:01 UTC

Severity: normal

Full log


View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Michael Stone <mstone <at> debian.org>, Pádraig Brady <P <at> draigbrady.com>
Cc: 1058752 <at> bugs.debian.org, 62572 <at> debbugs.gnu.org
Subject: bug#62572: cp --no-clobber behavior has changed
Date: Fri, 15 Dec 2023 11:21:06 -0800
On 2023-12-15 10:49, Michael Stone wrote:
> There's no compelling reason to force this change

Well, certainly nobody compelled us at gunpoint....

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.


> Essentially the current situation is that -n shouldn't be used if you expect a certain behavior for this case and you are writing a script for linux systems. Maybe in 10 years you'll be able to assume the new behavior. Better to just tell people to not use it at all, and leave the historic behavior alone until everyone has stopped using -n entirely.

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

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 bug report was last modified 1 year and 175 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.