Another rfe: "cp" this time

[Bruce Korb]

Our corporate infrastructure only allows CIFS shares.  No FTP access.
No scp access.  Nope.  Gotta be CIFS.  One of these is on the other
side of the pond.  The pipe is fairly fat, but very, very long.
Sometimes, like yesterday, after 8 hours of copying, I was only
80% complete and I had to shut down and go home, other times, the
operation has been interrupted.  So I am proposing two options
for "cp":  --resume and --parallel
I'll let you guess what --resume does, --parallel would open the
source file several times and have multiple threads reading and
writing different parts of the file.

I can either add this to cp, or roll my own toy.  What say you?

Thanks - Bruce

P.S. The other weekend, I played with the character classifier
thingy.  The performance results are going to surprise you:
it's data dependent.  If the sought character in strpbrk/strcspn
is right at the start, not having to do the setup is a win.
After about 64 bytes, the assembly code always wins.  In between,
it depends on the number of characters in the character class,
but the crossover was always in the 10 - 64 byte range.
The one outlier is the 1 byte character class wherein strpbrk
takes several hundred times longer than when it is a 2 byte class.