GNU bug report logs -
#15738
cp: "cp -a A B" doesn't reliably create 'B' as copy of A
Previous Next
Full log
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
with "--remove-destination", I think this a bug. W/o it, it is
inconsistent with the requirement not to use "dirname/." to refer to
contents in 'rm'.
details:
mkdir a
touch a/file
mkdir a/dir
cp -a a b #'ok'
touch a/file2
now:
cp -au a b
(or)
cp -a a b
Either form creates another complete copy of 'a' in directory 'b'.
(Note, this is historical behavior).
FWIW,
cp -a a/ b/
behaves the same way.
However,
cp -a a/. b/.
fails the 1st time, but not if 'b' is already created (by using a form
from above).
Technically, though, the above should fail, as it says
says to copy the dir-entry for '.' over the dot entry
in 'b'.
While using '.' as a shorthand for contents of a dir has been
normal, it no longer works in utils like 'rm'.
---!!!---
*More troublesome* is that:
cp -a --remove-destination a b
doesn't work, but duplicates the behaviors of the above.
If 'b' is removed *before* the copy, as is documented,
then it should be no different than the case where 'a' is
copied to a non-existent 'b'.
This bug report was last modified 6 years and 157 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.