GNU bug report logs - #31335
unexpected cp -f behavior

Previous Next

Full log

Message #19 received at 31335 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 31335 <at> debbugs.gnu.org, P <at> draigBrady.com, erjoalgo <at> gmail.com
Subject: Re: bug#31335: Fwd: bug#31335: unexpected cp -f behavior
Date: Tue, 15 May 2018 17:11:25 -0700

On 05/15/2018 10:05 AM, Pádraig Brady wrote:
>> It's also what I would expect, if I use -f, I expect cp will do everything
>> it can to force the operation and succeed if all possible.
> Maybe, though that's worth further consideration.

POSIX is arguably ambiguous about what 'cp -f S D' should do if D is a 
symlink to itself. POSIX says that if D "exists", then cp must try to 
unlink and then re-create D; and that if D does not "exist", cp must 
fail. So, if one considers a self-symlink as "existing", then GNU cp 
doesn't conform to POSIX; if one considers such a symlink as not 
"existing", then GNU cp conforms. Unfortunately, as far as I can tell 
POSIX never exactly defines what "exists" means in this context.

That being said, POSIX uses nearly the same wording for 'ln -f' that it 
does for 'cp -f', which implies that cp should be consistent with ln, 
and GNU ln (like most ln implementations) treat self-symlinks as 
"existing" in this case. Also, other implementations of cp seem act like 
ln does here, so they interpret the ambiguity in POSIX the opposite way 
that GNU cp does. Furthermore, I think that users by and large expect 
the non-GNU interpretation where 'cp -f' is like 'ln -f'. For all these 
reasons, I'm inclined to think that GNU cp should fall into line here.

Previous Next

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