bug#13135: Loss of data while copying

[John Reiser]

On 12/10/2012 10:03 AM, Eric Blake wrote:
> On 12/10/2012 10:06 AM, John Reiser wrote:
>>> Yes, because a count was specified,
>>> dd will operate in its default awkward but POSIX specified mode
>>> of counting each read() call, even if it returned less than specified.
>>> This is especially noticeable with pipes:
>>
>> So this bug report is really about the execrable documentation for 'dd'.
>> Despite similar complaints appearing yearly [or so],
>> the text of "info dd" does not contain the string "pipe".  SHAME ON 
>> COREUTILS.
>> Explaining the most common error, and how to avoid it, certainly does
>> belong in the documentation.  The purpose of documentation is to *FACILITATE*
>> the correct use of the tool, and not merely to erect the minimal legal 
>> defense
>> of the code.
> 
> Rather than complaining, how about you submit a patch to improve the
> documentation?
> 

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 21400ad..c2282eb 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -8055,6 +8055,7 @@ OS/360 JCL.
 @item address@hidden
 @opindex if
 Read from @var{file} instead of standard input.
+(If the input is a pipe then see @samp{fullblock} below.)

 @item address@hidden
 @opindex of
@@ -8397,6 +8398,9 @@ may return early if a full block is not available.
 When that happens, continue calling @code{read} to fill the remainder
 of the block.
 This flag can be used only with @code{iflag}.
+If the input is a pipe and argument @samp{count=} also is specified,
+then probably @samp{iflag=fullblock} should be used
+in order to prevent surprises caused by short reads.

 @item count_bytes
 @opindex count_bytes


--