From owner-freebsd-questions@FreeBSD.ORG  Fri Mar 29 01:17:24 2013
Return-Path: <owner-freebsd-questions@FreeBSD.ORG>
Delivered-To: freebsd-questions@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by hub.freebsd.org (Postfix) with ESMTP id 851F792D
 for <freebsd-questions@freebsd.org>; Fri, 29 Mar 2013 01:17:24 +0000 (UTC)
 (envelope-from rfg@tristatelogic.com)
Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com
 [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 679B9F77
 for <freebsd-questions@freebsd.org>; Fri, 29 Mar 2013 01:17:24 +0000 (UTC)
Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1])
 by segfault.tristatelogic.com (Postfix) with ESMTP id CFC143BB5F
 for <freebsd-questions@freebsd.org>; Thu, 28 Mar 2013 18:17:23 -0700 (PDT)
From: "Ronald F. Guilmette" <rfg@tristatelogic.com>
To: freebsd-questions@freebsd.org
Subject: Re: Copying memstick image to a USB (flash/thumb) drive
In-Reply-To: <51543B7A.4030300@qeng-ho.org>
Date: Thu, 28 Mar 2013 18:17:23 -0700
Message-ID: <26455.1364519843@server1.tristatelogic.com>
X-BeenThere: freebsd-questions@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: User questions <freebsd-questions.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-questions>, 
 <mailto:freebsd-questions-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-questions>
List-Post: <mailto:freebsd-questions@freebsd.org>
List-Help: <mailto:freebsd-questions-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-questions>, 
 <mailto:freebsd-questions-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Mar 2013 01:17:24 -0000


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