Comment 6 for bug 154602

2009/3/31 C de-Avillez <email address hidden>:
> Interesting. Jim Meyring's answer did not make it here (although,
> AFAICS, it was correctly addressed). So, here it is:
>
> Jens Ropers wrote:
>> 2009/3/30 jaduncan <email address hidden>:
>>> This is correct behaviour as per POSIX - it's how it should work!
>>
>> Says who?
>
> I'm confident that POSIX does not require
> cp -r dir dir to create dir/dir ;-)

Just to clarify again, what bothers me about this is that cp says that
is can't copy a directory into itself *and then does it anyway, once*.

[I.] If it said that it can't do it and then didn't do it, that would be fine.

[II.] If it accepted the recursive directory copying command and tried
to execute it until it errored out because the path got too long, that
would be fine as well. Possibly a bit crude, but better than the
current inconsistency between what it says it can't do and what it
still does.

I tried this on OpenBSD 4.3 for comparison purposes:

Unlike GNU's coreutils cp(1), OpenBSD's cp(1) --which is derived from
AT&T UNIX Version 1-- expressly says on its man page that it is
POSIX-compliant: http://www.openbsd.org/cgi-bin/man.cgi?query=cp
OpenBSD's cp(1) behaves as described under [II.]: It recursively
copies foo into itself until the path becomes too long, at which stage
it produces an error message and stops copying any further. This
produces a long subtree of foo/foo/foo/foo... and so forth, and the
testfile is also present at each level. Again, this may seem more
bare-bones, as it doesn't attempt to catch attempts at recursive
copying beforehand, but it's actually more consistent and more logical
and doesn't do anything it said it couldn't do.

So apologies if I'm being impolite, but I'm more inclined to believe
that OpenBSD's cp(1) really is POSIX-compliant --as its man page says
it is-- than I am inclined to believe jaduncan's claim that GNU
coreutils cp(1) was POSIX-compliant.
Of course it's also possible that POSIX doesn't specify at all how
cp(1) should behave in this case. But that too would only invalidate
jaduncan's citation of POSIX compliance in his objection.

And yes, I absolutely believe that it makes good sense to keep this
open as a tracking bug here, and to take it up with upstream. And
--apologies again-- but I'm sceptical of the declaration that the GNU
project would not want to change this; asking won't hurt.

Thanks and regards,
--ropers

>>> This is something that would be an upstream bug, but they will not want
>>> to change this behaviour.
>>
>> Well, have you asked them?
>
> I don't like the existing behavior, but this is a rather hairy corner of
> copy.c already, and considering we're talking about the state left after
> the user runs a bogus command (which is surprisingly hard to detect _in
> general_), I'm in no big hurry to fix it.
>
> However, if someone sends in a perfect patch,
>
>  http://git.sv.gnu.org/cgit/coreutils.git/plain/HACKING
>
> I'll be very interested.