[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#13135: Loss of data while copying
From: |
John Reiser |
Subject: |
bug#13135: Loss of data while copying |
Date: |
Mon, 10 Dec 2012 09:06:09 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 |
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.
--