Date: Thu, 28 Mar 2013 18:17:23 -0700 From: "Ronald F. Guilmette" <rfg@tristatelogic.com> To: freebsd-questions@freebsd.org Subject: Re: Copying memstick image to a USB (flash/thumb) drive Message-ID: <26455.1364519843@server1.tristatelogic.com> In-Reply-To: <51543B7A.4030300@qeng-ho.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <51543B7A.4030300@qeng-ho.org>, Arthur Chance <freebsd@qeng-ho.org> wrote: >On 03/28/13 10:32, Ronald F. Guilmette wrote: >> It is possible, I would guess, that dd may notice the EOF occuring >> before it has filled up an entire input buffer, and then just quit >> at that point, _without_ writing the partial last block to the >> output device. > >It will attempt to write a short block. E.g. > >arthur@fileserver[2]> ls -l t.pdf >-rw-rw-r-- 1 arthur arthur 233812 Feb 18 12:26 t.pdf >arthur@fileserver[2]> dd if=t.pdf of=/dev/null bs=1k >228+1 records in >228+1 records out >233812 bytes transferred in 0.036731 secs (6365521 bytes/sec) > >Those +1 records are the final short block. OK. Thanks. That's definitely good to know. I wonder if this behavior is documented in the man page. (It certainly should be, if it isn't already.) >> It seems to me that conv=sync is cheap insurance against this >> possibility. > >It's used as an insurance against output devices which have a fixed (or >in the case of tape, a minimum) block size. If the short block is not an >exact integer multiple of the device block size then the final write >will fail. Right. I understand. >conv=sync and a bs (or obs) that's a strict multiple of block >size prevents the problem. That's exactly your use case. Right. Regards, rfg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?26455.1364519843>