huge incompatible change in cp

[Matthias Benkmann]

Okay, please someone tell me that fileutils 4.1 is just a nasty joke. Who 
could possibly have come up with the idea of introducing a huge 
incompatible change into one of the most widely used programs in the GNU 
world?

cp -f is supposed to remove files before copying. This has been its 
behaviour for a long time. Did it not occur to anyone that the target 
might be a hard link, or a FIFO, or whatever.

The new cp -f has completely different semantics for those cases. 
Especially the hard link case is a horror. Look at this

cd /lib
ln libc.so.6 mylibc
.... testing with gnu libc as long as mylibc is not written
...
cp -f realmylibc mylibc

With fileutils-4.0 everything is fine, but with fileutils-4.1 it's a big 
"Oops. I've just wasted my libc."

Making this change was an irresponsible act by the fileutils maintainers. 

And besides, you forgot to add a switch to suppress prompting the user now 
that -f does not negate -i anymore. You know that alias cp='cp -i' is 
standard on many installations these days. There needs to be an option to 
cancel the -i. 

MSB

----
The best time to plant a tree was 20 years ago - 

The second best is now!