GNU bug report logs - #34923
dd: add messages about IO errors

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: coreutils; Severity: wishlist; Reported by: "Daniel A. Gauthier" <fractal2010@HIDDEN>; Keywords: notabug; dated Wed, 20 Mar 2019 01:55:02 UTC; Maintainer for coreutils is bug-coreutils@HIDDEN.
Changed bug title to 'dd: add messages about IO errors' from 'Message/race bug in 'dd'' Request was from Assaf Gordon <assafgordon@HIDDEN> to control <at> debbugs.gnu.org. Full text available.
Severity set to 'wishlist' from 'normal' Request was from Assaf Gordon <assafgordon@HIDDEN> to control <at> debbugs.gnu.org. Full text available.
Added tag(s) notabug. Request was from Assaf Gordon <assafgordon@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Message received at 34923 <at> debbugs.gnu.org:


Received: (at 34923) by debbugs.gnu.org; 28 Mar 2019 17:57:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 28 13:57:15 2019
Received: from localhost ([127.0.0.1]:34651 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1h9ZH9-0002i0-2m
	for submit <at> debbugs.gnu.org; Thu, 28 Mar 2019 13:57:15 -0400
Received: from mail-pf1-f175.google.com ([209.85.210.175]:40145)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <assafgordon@HIDDEN>)
 id 1h9ZH6-0002hf-P9; Thu, 28 Mar 2019 13:57:13 -0400
Received: by mail-pf1-f175.google.com with SMTP id c207so11707245pfc.7;
 Thu, 28 Mar 2019 10:57:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=subject:to:references:from:message-id:date:user-agent:mime-version
 :in-reply-to:content-language:content-transfer-encoding;
 bh=sDbnvjqWkfyP6zUI5Pt4OtbZBRWHKuUjxClr53CMITc=;
 b=AS50dIK8aD/BOdYrNaM4fjzV4ZNvpDzxZkK71z6mAM4XypXq7T9G+zta54tUs/kVT4
 O1BrygoA3L7QH4bYdpZNN/nNdJBZCRhFVTWpQZ01xKqi2TtlvQYYzrFL8y917wRkwf+9
 yN1HOfe4NczDJTU51DwWNDTHjENztPoQ+VSmfO8ldCO/HJtFKAUdWgMsN/imMGf5QdHm
 JtDG3T/L8u5Hayu3SgT/NfsgEUADvXcBX7w4A8T0g87tp3w3UFY3mcJK3QmOffSSmg6B
 HBluF5gRqwZjjO9qJuWm2KBnKmAhc7WoUacF2ZbLwjpsG8+ZVZMRm/e+Ylwzsn+vlebk
 7Zfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:subject:to:references:from:message-id:date
 :user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=sDbnvjqWkfyP6zUI5Pt4OtbZBRWHKuUjxClr53CMITc=;
 b=fB+QQSlbfUy8uuSiW8ni9BMxTltxRbU0hh+4ECel0hb/caAH1iAFbbdokVxNt8zEa7
 AwgfwiP9GiUljuhId8qx3iT1xh9ScbQ4vyePTWVCcTxhv4E1P8dxn9PzYjZo9yLPzPJC
 ovqBSf1HBYGAslSb8sA3ISR1TXzrCFjZ9/R6ANtT/xe0EXscLxds75VqhGzvqHOmUJn5
 D+ipQipPESL3ULbSLw/nnXAm7X4KEx7FLQhbmMdgnjuw1SqX/4sClhBTrbARjN0BGqa2
 KTIUaFw6DJ0y3YU8w/pkH5JzBwMp05rT/mX2l5cZIDIa81DrbBW6yNNjJyS5xE31GOzm
 syBw==
X-Gm-Message-State: APjAAAVQOvWfnofk9K4oeCg15wh5KHfcosK6oyJrhV6BtGpe0rYfnB/T
 10aGIMD6+ttc9RltWFLjqr2oMzqm
X-Google-Smtp-Source: APXvYqx1zjL7KvpIzUcSLUX7MHQNSdBo3qB/Zg2md7MtBKgG2DI8H6VfANJ5IKtYSLr28JYaqiL3xQ==
X-Received: by 2002:a63:b03:: with SMTP id 3mr2595522pgl.267.1553795826264;
 Thu, 28 Mar 2019 10:57:06 -0700 (PDT)
Received: from tomato.housegordon.com (moose.housegordon.com. [184.68.105.38])
 by smtp.googlemail.com with ESMTPSA id
 d15sm12365159pfo.34.2019.03.28.10.57.04
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Thu, 28 Mar 2019 10:57:05 -0700 (PDT)
Subject: Re: bug#34923: Message/race bug in 'dd'
To: Paul Eggert <eggert@HIDDEN>,
 "Daniel A. Gauthier" <fractal2010@HIDDEN>, 34923 <at> debbugs.gnu.org
References: <vzggNN00.1553042504.1444600.fractal2010@HIDDEN>
 <b077c20f-727b-53de-807e-e0f5d6f99f35@HIDDEN>
From: Assaf Gordon <assafgordon@HIDDEN>
Message-ID: <e9f85585-e634-f250-11e1-20158a998239@HIDDEN>
Date: Thu, 28 Mar 2019 11:57:04 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <b077c20f-727b-53de-807e-e0f5d6f99f35@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 34923
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

tags 34923 notabug
severity 34923 wishlist
retitle 34923 dd: add messages about IO errors
stop

On 2019-03-19 9:44 p.m., Paul Eggert wrote:
> Daniel A. Gauthier wrote:
>> NOTICE that the "+nn" value on the line is always one off.  It says +0
>> after the first error, +1 after the second, etc. until the correct count
>> of error/short blocks is given at the end.
> 
> The count is supposed to just count short blocks, not errors. This is a 
> POSIX requirement. I installed the attached documentation patch to try 
> to make this clearer.

The documentation improvement was added here:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=59e01d13e600be0d2c7f08f3aff8cf11936b3ea1


> Perhaps dd should output a separate line to stderr that summaries I/O 
> errors; it could do that without violating POSIX.

Marking this as a wishlist item.

-assaf






Information forwarded to bug-coreutils@HIDDEN:
bug#34923; Package coreutils. Full text available.

Message received at 34923 <at> debbugs.gnu.org:


Received: (at 34923) by debbugs.gnu.org; 20 Mar 2019 03:44:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 19 23:44:53 2019
Received: from localhost ([127.0.0.1]:51123 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1h6S9t-0000dG-A7
	for submit <at> debbugs.gnu.org; Tue, 19 Mar 2019 23:44:53 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:58836)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1h6S9q-0000d0-Fd
 for 34923 <at> debbugs.gnu.org; Tue, 19 Mar 2019 23:44:52 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 39C80160861;
 Tue, 19 Mar 2019 20:44:44 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id eGLaQepGv7kE; Tue, 19 Mar 2019 20:44:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id ED58516086B;
 Tue, 19 Mar 2019 20:44:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id 0mZvxCONzeWu; Tue, 19 Mar 2019 20:44:42 -0700 (PDT)
Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com
 [23.242.74.103])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id C2558160834;
 Tue, 19 Mar 2019 20:44:42 -0700 (PDT)
Subject: Re: bug#34923: Message/race bug in 'dd'
To: "Daniel A. Gauthier" <fractal2010@HIDDEN>, 34923 <at> debbugs.gnu.org
References: <vzggNN00.1553042504.1444600.fractal2010@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <b077c20f-727b-53de-807e-e0f5d6f99f35@HIDDEN>
Date: Tue, 19 Mar 2019 20:44:42 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <vzggNN00.1553042504.1444600.fractal2010@HIDDEN>
Content-Type: multipart/mixed; boundary="------------218E025BB320B8A4D9ACAD46"
Content-Language: en-US
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 34923
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

This is a multi-part message in MIME format.
--------------218E025BB320B8A4D9ACAD46
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Daniel A. Gauthier wrote:
> NOTICE that the "+nn" value on the line is always one off.  It says +0
> after the first error, +1 after the second, etc. until the correct count
> of error/short blocks is given at the end.

The count is supposed to just count short blocks, not errors. This is a POSIX 
requirement. I installed the attached documentation patch to try to make this 
clearer.

Perhaps dd should output a separate line to stderr that summaries I/O errors; it 
could do that without violating POSIX.

--------------218E025BB320B8A4D9ACAD46
Content-Type: text/x-patch;
 name="0001-dd-improve-doc-of-stderr-output.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="0001-dd-improve-doc-of-stderr-output.patch"

From 59e01d13e600be0d2c7f08f3aff8cf11936b3ea1 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@HIDDEN>
Date: Tue, 19 Mar 2019 20:08:41 -0700
Subject: [PATCH] dd: improve doc of stderr output

* doc/coreutils.texi (dd invocation):
Document stderr output more carefully.
Say that conv=block can lose input data.
---
 doc/coreutils.texi | 53 ++++++++++++++++++++++++++++++----------------
 1 file changed, 35 insertions(+), 18 deletions(-)

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 0a2539d82..c8ca44cdd 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -9073,7 +9073,7 @@ The default is 512 bytes.
 Set both input and output block sizes to @var{bytes}.
 This makes @command{dd} read and write @var{bytes} per block,
 overriding any @samp{ibs} and @samp{obs} settings.
-In addition, if no data-transforming @option{conv} option is specified,
+In addition, if no data-transforming @option{conv} operand is specified,
 input is copied to the output as soon as it's read,
 even if it is smaller than the block size.
 
@@ -9114,10 +9114,9 @@ input read operations.
 
 @item status=@var{level}
 @opindex status
-Transfer information is normally output to stderr upon
-receipt of the @samp{INFO} signal or when @command{dd} exits.
-Specifying @var{level} will adjust the amount of information printed,
-with the last @var{level} specified taking precedence.
+Specify the amount of information printed.
+If this operand is given multiple times, the last one takes precedence.
+The @var{level} value can be one of the following:
 
 @table @samp
 
@@ -9140,6 +9139,23 @@ can be delayed when waiting on I/O.
 
 @end table
 
+Transfer information is normally output to stderr upon
+receipt of the @samp{INFO} signal or when @command{dd} exits,
+and defaults to the following form in the C locale:
+
+@example
+7287+1 records in
+116608+0 records out
+59703296 bytes (60 MB, 57 MiB) copied, 0.0427974 s, 1.4 GB/s
+@end example
+
+The notation @samp{@var{w}+@var{p}} stands for @var{w} whole blocks
+and @var{p} partial blocks.  A partial block occurs when a read or
+write operation succeeds but transfers less data than the block size.
+An additional line like @samp{1 truncated record} or @samp{10
+truncated records} is output after the @samp{records out} line if
+@samp{conv=block} processing truncated one or more input records.
+
 @item conv=@var{conversion}[,@var{conversion}]@dots{}
 @opindex conv
 Convert the file as specified by the @var{conversion} argument(s).
@@ -9154,14 +9170,14 @@ Conversions:
 Convert EBCDIC to ASCII,
 using the conversion table specified by POSIX@.
 This provides a 1:1 translation for all 256 bytes.
-This option implies @samp{conv=unblock}; input is converted to
+This implies @samp{conv=unblock}; input is converted to
 ASCII before trailing spaces are deleted.
 
 @item ebcdic
 @opindex ebcdic@r{, converting to}
 Convert ASCII to EBCDIC@.
 This is the inverse of the @samp{ascii} conversion.
-This option implies @samp{conv=block}; trailing spaces are added
+This implies @samp{conv=block}; trailing spaces are added
 before being converted to EBCDIC@.
 
 @item ibm
@@ -9172,13 +9188,14 @@ This is not a 1:1 translation, but reflects common historical practice
 for @samp{~}, @samp{[}, and @samp{]}.
 
 The @samp{ascii}, @samp{ebcdic}, and @samp{ibm} conversions are
-mutually exclusive.  If you use any of these options, you should also
-use the @samp{cbs=} option.
+mutually exclusive.  If you use any of these conversions, you should also
+use the @samp{cbs=} operand.
 
 @item block
 @opindex block @r{(space-padding)}
 For each line in the input, output @samp{cbs} bytes, replacing the
-input newline with a space and padding with spaces as necessary.
+input newline with a space and truncating or padding input lines with
+spaces as necessary.
 
 @item unblock
 @opindex unblock
@@ -9202,13 +9219,13 @@ The @samp{lcase} and @samp{ucase} conversions are mutually exclusive.
 Try to seek rather than write NUL output blocks.
 On a file system that supports sparse files, this will create
 sparse output when extending the output file.
-Be careful when using this option in conjunction with
+Be careful when using this conversion in conjunction with
 @samp{conv=notrunc} or @samp{oflag=append}.
 With @samp{conv=notrunc}, existing data in the output file
 corresponding to NUL blocks from the input, will be untouched.
 With @samp{oflag=append} the seeks performed will be ineffective.
 Similarly, when the output is a device rather than a file,
-NUL input blocks are not copied, and therefore this option
+NUL input blocks are not copied, and therefore this conversion
 is most useful with virtual or pre zeroed devices.
 
 @item swab
@@ -9341,7 +9358,7 @@ failure to discard the cache is diagnosed
 and reflected in the exit status.
 
 Note data that is not already persisted to storage will not
-be discarded from cache, so note the use of the ``sync'' options
+be discarded from cache, so note the use of the @samp{sync} conversions
 in the examples below, which are used to maximize the
 effectiveness of the @samp{nocache} flag.
 
@@ -9382,7 +9399,7 @@ idea to test it on your files before relying on it.
 @cindex controlling terminal
 Do not assign the file to be a controlling terminal for @command{dd}.
 This has no effect when the file is not a terminal.
-On many hosts (e.g., GNU/Linux hosts), this option has no effect
+On many hosts (e.g., GNU/Linux hosts), this flag has no effect
 at all.
 
 @item nofollow
@@ -9398,13 +9415,13 @@ Fail if the file has multiple hard links.
 @item binary
 @opindex binary
 @cindex binary I/O
-Use binary I/O@.  This option has an effect only on nonstandard
+Use binary I/O@.  This flag has an effect only on nonstandard
 platforms that distinguish binary from text I/O.
 
 @item text
 @opindex text
 @cindex text I/O
-Use text I/O@.  Like @samp{binary}, this option has no effect on
+Use text I/O@.  Like @samp{binary}, this flag has no effect on
 standard platforms.
 
 @item fullblock
@@ -9490,7 +9507,7 @@ disk finally dies, e.g.
 However, in some cases such a tool is not available or the administrator
 feels more comfortable with the handling of @command{dd}.
 As a simple rescue method, call @command{dd} as shown in the following
-example: the options @samp{conv=noerror,sync} are used to continue
+example: the operand @samp{conv=noerror,sync} is used to continue
 after read errors and to pad out bad reads with NULs, while
 @samp{iflag=fullblock} caters for short reads (which traditionally never
 occur on disk based devices):
@@ -9532,7 +9549,7 @@ The above script will output in the following format:
 5000000000 bytes (5.0 GB, 4.7 GiB) copied, 1.44433 s, 3.5 GB/s
 @end example
 
-The @samp{status=progress} option periodically updates the last line
+The @samp{status=progress} operand periodically updates the last line
 of the transfer statistics above.
 
 @vindex POSIXLY_CORRECT
-- 
2.17.1


--------------218E025BB320B8A4D9ACAD46--




Information forwarded to bug-coreutils@HIDDEN:
bug#34923; Package coreutils. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 20 Mar 2019 01:54:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 19 21:54:48 2019
Received: from localhost ([127.0.0.1]:51088 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1h6QRM-0004Fy-Bk
	for submit <at> debbugs.gnu.org; Tue, 19 Mar 2019 21:54:48 -0400
Received: from eggs.gnu.org ([209.51.188.92]:53180)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <fractal2010@HIDDEN>) id 1h6Pfg-0002yN-0G
 for submit <at> debbugs.gnu.org; Tue, 19 Mar 2019 21:05:34 -0400
Received: from lists.gnu.org ([209.51.188.17]:41616)
 by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <fractal2010@HIDDEN>)
 id 1h6PfW-0002WH-82
 for submit <at> debbugs.gnu.org; Tue, 19 Mar 2019 21:05:24 -0400
Received: from eggs.gnu.org ([209.51.188.92]:38585)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <fractal2010@HIDDEN>) id 1h6PfU-0002Ny-VZ
 for bug-coreutils@HIDDEN; Tue, 19 Mar 2019 21:05:22 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled
 version=3.3.2
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <fractal2010@HIDDEN>) id 1h6PXE-0007ZA-Kk
 for bug-coreutils@HIDDEN; Tue, 19 Mar 2019 20:56:49 -0400
Received: from beyond.12am.net ([64.7.173.87]:49891)
 by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <fractal2010@HIDDEN>)
 id 1h6PX0-0005ca-Eb
 for bug-coreutils@HIDDEN; Tue, 19 Mar 2019 20:56:48 -0400
Received: from beyond.10 (localhost [127.0.0.1])
 by beyond.12am.net (8.13.4/8.13.4) with ESMTP id x2K0fjEu022239
 for <bug-coreutils@HIDDEN>; Tue, 19 Mar 2019 20:41:45 -0400
Received: (from daemon@localhost)
 by beyond.10 (8.13.4/8.13.4/Submit) id x2K0fiRD022237;
 Tue, 19 Mar 2019 20:41:44 -0400
Date: Tue, 19 Mar 2019 20:41:44 -0400
To: bug-coreutils@HIDDEN
Subject: Message/race bug in 'dd'
Received: from 10.100.1.157 (auth. user fractal2010@HIDDEN)
 by www.empireind.com with HTTP; Tue, 19 Mar 2019 20:41:44 -0400
X-IlohaMail-Blah: fractal2010@HIDDEN
X-IlohaMail-Method: mail() [mem]
X-IlohaMail-Dummy: moo
X-Mailer: IlohaMail/0.8.14 (On: www.empireind.com)
Message-ID: <vzggNN00.1553042504.1444600.fractal2010@HIDDEN>
From: "Daniel A. Gauthier" <fractal2010@HIDDEN>
Bounce-To: "Daniel A. Gauthier" <fractal2010@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x
X-Received-From: 64.7.173.87
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Spam-Score: 0.9 (/)
X-Debbugs-Envelope-To: submit
X-Mailman-Approved-At: Tue, 19 Mar 2019 21:54:47 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.1 (/)


Coreutils / DD / stderr output warning / Timing or count error:

I may or may not have reported this bug many years (decade?) ago and just
noticed it's still there.

Correct example.

dd
<data>
^D
0+1 records in
0+1 records out
Other timing/byte counts, kb/s, etc., in this case 7 bytes (the
"<data>" is literal) - the +1 is due to short block.

This works fine as long as you aren't using "conv=sync,noerror".

If you are, however, then do a:

dd conv=sync,noerror if=file-with-bad-spots.dat
of=newfile-without-,-hopefully.dat
(sometime after...)
0+0 records in
0+0 records out
dd: read error on file-with-bad-spots.dat
Usual other timing/byte counts, etc. are correct (AFAIK)
(-- a few minutes goes by ... --)
0+1 records in
0+0 records out
dd: read error (again, yadayadayada)
(many more minutes...)
0+2 records in
0+0 records out
Timing, counts, etc.
Total bytes per the file copied, etc. all appear to be correct and the
"+nn+ is the number of bad spots.

NOTICE that the "+nn" value on the line is always one off.  It says +0
after the first error, +1 after the second, etc. until the correct count
of error/short blocks is given at the end.  My utility program monitors
the output of dd's stderr and prints a colored warning message whenever
the "+nn" count goes up, but it doesn't go up right away.  Even
worse, if you are using USR1 to signal on a regular schedule, as I do,
the error is indicated to the program long after the error actually
occurred and the included byte count does NOT point to the bad spot. 
(The subsequent USR1 signals indicate the current error count, but the
one that was printed WITH the error message does not)

I hope there's no historical reason for this, I might be able to test
other versions to see if it's there also.  It just seems to me that
from a design perspective, I see a number of reasons why the text
printed to stderr at the time the error is encountered should be
consistent and reflective of the error that caused it to be printed, and
I have no reason why the phase of the number stream versus the input
stream should matter to anything else.  Combine that with the fact that
it appears it should be an easy change and I'm hoping someone familiar
with the code could kick out a patch in 3 or 4 minutes that'd take me
much longer having no familiarity with the code.  (But if I ever get
free time I might take a look).

The obvious assumption is that a "++err_count" line needs to be moved
up 1 or 2 lines.

I've had various accounts on tracking systems over the years, but my
attention span is really short.

Daniel A. Gauthier
aka Fractal







Acknowledgement sent to "Daniel A. Gauthier" <fractal2010@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-coreutils@HIDDEN. Full text available.
Report forwarded to bug-coreutils@HIDDEN:
bug#34923; Package coreutils. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Mon, 25 Nov 2019 12:00:02 UTC

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