stupid cp(1) behaviour

[Alexander Best]

is there a chance to change cp's behaviour in connection with the -R switch, so
that it stops after the first error? i just ran into the following situation:

1) cp -ai bla /mnt/umass
2) i got a lot of warnings that /mnt/umass was full
3) cp -an bla /mnt/umass
4) ...that didn't work, since cp created 0 byte files for all files it couldn't
   copy in 1.
5) what i had to do is 'find /mnt/umass/bla -type f - size 0 -delete' and then
   try 3 again

of course, if cp would have bailed out after the first error, there still would
be one file with < actual file size. maybe the available filesize could be
checked before crating the file, or another possibility:

implement a new -N switch or so which isn't based on a file's existance, but a
file's checksum.

cheers.
alex