GNU bug report logs - #13135
Loss of data while copying

Previous Next

Full log

Message #18 received at submit <at> debbugs.gnu.org (full text, mbox):

From: John Reiser <jreiser <at> bitwagon.com>
To: bug-coreutils <at> gnu.org
Subject: Re: bug#13135: Loss of data while copying
Date: Mon, 10 Dec 2012 09:06:09 -0800

On 12/10/2012 07:21 AM, Pádraig Brady wrote:

>> On 12/10/2012 07:58 AM, Cojocaru Alexandru wrote:
>>> bash$ yes $(for i in $(seq 1 100000); do echo -n a; done) | dd of=big-lines ibs=100001 count=10000
>>> 9924+76 records in

The original poster should know better: the best bug reports include
not only what actually happened, but also the version number of the components,
what the original poster expected to happen, and an explicit identification
of the differences.  For instance:

   (I am running dd from coreutils-8.15.)
   The 'yes' will generate an infinite stream of lines, each containing
   one hundred thousand 'a' characters followed by a terminating newline.
   I expect that "ibs=100001" causes dd to read each entire line (including
   the newline) in one operation, and that "count=10000" causes dd to stop
   after copying ten thousand lines.  Thus the dd summary should say:
      10000 records in
      10000 records out
      1000010000 bytes (1000 MB) copied


> 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.

-- 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.