GNU bug report logs -
#31335
unexpected cp -f behavior
Previous Next
Full log
Message #22 received at 31335 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 15/05/18 17:11, Paul Eggert wrote:
> 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.
Well `test -e self-symlink` => does not exist
> 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.
Agreed. I can't think of a case where replacing a self symlink
is not what you'd want to happen.
Proposed patch is attached.
cheers,
Pádraig
[cp-f-eloop.patch (text/x-patch, attachment)]
This bug report was last modified 7 years and 57 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.