Re: cp by blocks, with errors

[Jim Meyering]

address@hidden (Bryan Henderson) wrote:
> I have two (related) enhancements to cp to propose.  Code is attached.
> Enhancement 1: reading by blocks
> Enhancement 2: handling of unreadable portions of source file
...
> I can do some of this with dd if I'm desperate, but dd is technically
> for a rather lower level job -- directly driving a device driver --
> not byte stream files.  It doesn't for example, deal with short reads
> in a byte stream way.

Thank you for the patches.
However, these are two fundamentally unrelated changes, so
they should be considered separately.

The first one looks like it's solely a performance optimization for the
case (common?) in which there are short reads.  Can you provide some
data to justify adding this code?  Do you have a feel for how often
cp gets short reads when block alignment would make a significant
difference in performance?

The second looks like it'd be more appropriate as an option for dd than
for cp, since dd already has a noerror option.  Can you give an example
showing why it'd be better to have this functionality in cp than in dd?
Isn't it necessary sometimes to use lseek to get past an unreadable bit
of media?