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: [root@h20:/disk2] mkdir a [root@h20:/disk2] touch a/1 a/2 a/3 [root@h20:/disk2] mkdir a/b [root@h20:/disk2] touch a/b/b [root@h20:/disk2] mkdir a/c [root@h20:/disk2] touch a/b/c [root@h20:/disk2] touch a/b/1 [root@h20:/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: [root@h20:/disk2] mkdir a [root@h20:/disk2] touch a/1 a/2 a/3 [root@h20:/disk2] mkdir a/b [root@h20:/disk2] touch a/b/b [root@h20:/disk2] mkdir a/c [root@h20:/disk2] touch a/b/c [root@h20:/disk2] touch a/b/1 [root@h20:/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:[EMAIL PROTECTED] 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. ** _______________________________________________ Bug-fileutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-fileutils
