Bug (?) in cp

[Mike Croghan]

Hi GNU folks,

I've found a difference in behavior between the cp in fileutils-4.0x and 
the cp in fileutils-4.0.35.  I'm not sure if the new behavior is a bug, 
but I do know that I prefer the old behavior.  :-)  Here's the scoop:

Using fileutils-4.0x:

address@hidden:/disk2] mkdir a
address@hidden:/disk2] touch a/1 a/2 a/3
address@hidden:/disk2] mkdir a/b
address@hidden:/disk2] touch a/b/b
address@hidden:/disk2] mkdir a/c
address@hidden:/disk2] touch a/b/c
address@hidden:/disk2] touch a/b/1
address@hidden:/disk2] cp -al a/* a/b
cp: cannot create link `a/b/1': File exists
cp: cannot create directory `a/b/b': File exists
cp: cannot create directory `a/b/c': File exists

Using fileutils-4.0.35:

address@hidden:/disk2] mkdir a
address@hidden:/disk2] touch a/1 a/2 a/3
address@hidden:/disk2] mkdir a/b
address@hidden:/disk2] touch a/b/b
address@hidden:/disk2] mkdir a/c
address@hidden:/disk2] touch a/b/c
address@hidden:/disk2] touch a/b/1
address@hidden:/disk2] cp -al a/* a/b
cp: cannot create link `a/b/1': File exists
cp: won't create hard link `a/b/b/b' to directory `'

a/b/b and a/b/c (the files) have been blown away in favor of a/b/b and 
a/b/c (the directories) and their contents.  The old behavior, where you 
can use a file to "block" this kind of thing, is both convenient 
(especially to prevent recursion, although it seems like there's some 
odd belated safeguard against that in the new version) and more what I'd 
expect.  It seems a bit rude to blow away a file in favor of a directory 
while doing a recursive copy.

Thanks much,
Mike Croghan

--
Michael J. Croghan     mailto:address@hidden
Software Developer     703-558-8026
USATODAY.com           1000 Wilson Blvd., Arlington, VA  22229
** I do not speak for USATODAY.com, USA Today, or Gannett Co. **