<div dir="ltr"><div><div>It's pretty heavily used in combination with noerror. I can personally attest to its usefulness when working with both damaged optical media and spinning rust (with the correct blocksize in each case).<br><br></div>Each block read either contains blocksize data bytes or blocksize null bytes, so that the source and destination still have matching offsets.<br><br></div><div>Incidentally, I've seen this used to progressively recover all readable sectors on a damaged hard disk. Use a large multiple-of-hardware-sector-size blocksize to start. The destination file will retain (large) holes wherever there are bad blocks. searching for aligned blocks of nulls will give you lists of offsets to seek and skip to to retry with the smaller blocksize.<br><br></div><div>From what I've seen, if a blocksized read overlaps with a bad sector, once the kernel gives up on the sector, it fails the read without attempting any further sectors. Since (before the days of widespread block-remapping) sector failures often come in clusters, and avoiding reading bad sectors can improve the odds of getting all the not-yet-bad sectors, you can play iterative blocksize games to delay repeated risky reads until after most of the good data is recovered.<br><br></div><div>I *have* seen this used with non-blockdevices, although at the moment I can't recall the details (it wasn't recent).<br><br></div><div>Oddly enough, sync does what i expect. It's fsync and fdatasync that I was surprised by. Guess I'm showing my age ;)<br><br><br></div><div> <br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 9, 2017 at 5:39 PM, Samuel Holland <span dir="ltr"><<a href="mailto:samuel@sholland.org" target="_blank">samuel@sholland.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 07/09/17 17:07, Rob Landley wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
How is that useful?<br>
</blockquote>
<br></span>
It's very useful when trying to image dying hard disks, so bad sectors<br>
(that cause short reads or read failure) do not affect the alignment of<br>
the rest of the data in the image file.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Rob<span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
Samuel</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
Toybox mailing list<br>
<a href="mailto:Toybox@lists.landley.net" target="_blank">Toybox@lists.landley.net</a><br>
<a href="http://lists.landley.net/listinfo.cgi/toybox-landley.net" rel="noreferrer" target="_blank">http://lists.landley.net/listi<wbr>nfo.cgi/toybox-landley.net</a><br>
</div></div></blockquote></div><br></div>