On 07/09/2017 05:39 PM, Samuel Holland wrote: > On 07/09/17 17:07, Rob Landley wrote: >> Has anybody actually used the conv=sync option in the past 20 years? >> It doesn't do what you think (that's conv=fsync), instead it pads >> short reads with zeroes so the input block size is always the same. >> >> How is that useful? > > It's very useful when trying to image dying hard disks, so bad sectors > (that cause short reads or read failure) do not affect the alignment of > the rest of the data in the image file.
Does the read failure automatically advance the file pointer by the full amount, or does it have to lseek after the read? (I'm assuming the first, but that's an implementation detail I have so many questions about. I'm assuming your read block size is the device physical block size, and thus the short read isn't skipping data after the missing data which you otherwise could have read but gets turned into a short read because the read would otherwise have holes in it? How do you distinguish older 512 byte blocks from modern 4k blocks from whatever the heck flash block sizes are? I assume there's an ioctl() or something to find this out? Or do you just always use 512 bytes and hammering away at different parts of the same bad block eventually makes its way out the far side?) Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net