Your message dated Sun, 21 Aug 2005 12:30:33 -0400
with message-id <[EMAIL PROTECTED]>
and subject line Bug#324308: dd counts wrong from stdin
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 21 Aug 2005 14:15:51 +0000
>From [EMAIL PROTECTED] Sun Aug 21 07:15:51 2005
Return-path: <[EMAIL PROTECTED]>
Received: from mailgate1.uni-kl.de [131.246.120.5]
by spohr.debian.org with esmtp (Exim 3.36 1 (Debian))
id 1E6qc3-0005Dg-00; Sun, 21 Aug 2005 07:15:51 -0700
Received: from debian.localnet (rotes255.wohnheim.uni-kl.de [131.246.178.65])
by mailgate1.uni-kl.de (8.13.1/8.13.1) with ESMTP id j7LEFnvi002575;
Sun, 21 Aug 2005 16:15:49 +0200
Received: from inet by debian.localnet with local (Exim 4.52)
id 1E6qc0-0005sl-UE; Sun, 21 Aug 2005 16:15:49 +0200
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Eduard Bloch <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: dd counts wrong from stdin
X-Mailer: reportbug 3.15
Date: Sun, 21 Aug 2005 16:15:48 +0200
Message-Id: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE
autolearn=no version=2.60-bugs.debian.org_2005_01_02
Package: coreutils
Version: 5.2.1-2
Severity: grave
See output below. It does not make much sense. There seems to be a plan
behind that because the number of transfered bytes is increasing on
multiple retries. I guess there are some IPC problems, because it works
fine with if=file.
$ cat /mnt/c/pagefile.sys | dd
bs=1M count=200 | wc -c
80+120 records in
80+120 records out
88047616 bytes transferred in 0.616934 seconds (142718023 bytes/sec)
88047616
$ cat /mnt/c/pagefile.sys | dd
bs=1M count=200 | wc -c
77+123 records in
77+123 records out
89530368 bytes transferred in 0.509001 seconds (175894305 bytes/sec)
89530368
$ cat /mnt/c/pagefile.sys | dd
bs=1M count=200 | wc -c
82+118 records in
82+118 records out
91660288 bytes transferred in 0.558421 seconds (164141893 bytes/sec)
91660288
$ cat /mnt/c/pagefile.sys | dd
bs=1M count=200 | wc -c
84+116 records in
84+116 records out
94158848 bytes transferred in 0.607092 seconds (155098128 bytes/sec)
94158848
$ cat /mnt/c/pagefile.sys | dd
bs=1048576 count=200 | wc -c
89+111 records in
89+111 records out
95707136 bytes transferred in 0.639301 seconds (149705895 bytes/sec)
95707136
$ dd if=/mnt/c/pagefile.sys
bs=1048576 count=200 | wc -c
209715200
200+0 records in
200+0 records out
209715200 bytes transferred in 7.358449 seconds (28499919 bytes/sec)
$ cat /mnt/c/pagefile.sys | perl -e 'for(0..199) { my $buf; read(STDIN, $buf,
1048576); print $buf}' | wc -c
209715200
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.4
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Versions of packages coreutils depends on:
ii libacl1 2.2.29-1.0.1 Access control list shared library
ii libc6 2.3.5-3 GNU C Library: Shared libraries an
coreutils recommends no packages.
-- no debconf information
---------------------------------------
Received: (at 324308-close) by bugs.debian.org; 21 Aug 2005 16:30:35 +0000
>From [EMAIL PROTECTED] Sun Aug 21 09:30:35 2005
Return-path: <[EMAIL PROTECTED]>
Received: from vms046pub.verizon.net [206.46.252.46]
by spohr.debian.org with esmtp (Exim 3.36 1 (Debian))
id 1E6siR-0005F2-00; Sun, 21 Aug 2005 09:30:35 -0700
Received: from osgiliath.mathom.us ([151.200.14.55])
by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04
(built Dec 24 2004)) with ESMTPA id <[EMAIL PROTECTED]> for
[EMAIL PROTECTED]; Sun, 21 Aug 2005 11:30:34 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1])
by osgiliath.mathom.us (Postfix) with ESMTP id 6D95E60048A; Sun,
21 Aug 2005 12:30:33 -0400 (EDT)
Received: from osgiliath.mathom.us ([127.0.0.1])
by localhost (osgiliath [127.0.0.1]) (amavisd-new, port 10024)
with LMTP id 11451-01; Sun, 21 Aug 2005 12:30:33 -0400 (EDT)
Received: by osgiliath.mathom.us (Postfix, from userid 1000)
id 2F4556003F3; Sun, 21 Aug 2005 12:30:33 -0400 (EDT)
Date: Sun, 21 Aug 2005 12:30:33 -0400
From: Michael Stone <[EMAIL PROTECTED]>
Subject: Re: Bug#324308: dd counts wrong from stdin
In-reply-to: <[EMAIL PROTECTED]>
To: Eduard Bloch <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Message-id: <[EMAIL PROTECTED]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-disposition: inline
X-Pgp-Fingerprint: 53 FF 38 00 E7 DD 0A 9C 84 52 84 C5 EE DF 7C 88
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mathom.us
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
User-Agent: Mutt/1.5.10i
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
On Sun, Aug 21, 2005 at 06:05:01PM +0200, Eduard Bloch wrote:
>* Michael Stone [Sun, Aug 21 2005, 11:46:48AM]:
>> Nope, it makes perfect sense. You're asking for a fixed number of
>> ridiculously oversized records. It's extremely unlikely that you'll
>
>If that is ridiculous then I wonder why the upstream puts prefixes like
>M into the manpage.
Because they do make sense in some circumstances, such as reading or
writing a tape or block device. It also wouldn't be biting you here if
you weren't also specifying a specific number of records to read from
stdin. (If you weren't doing that then dd would just perform as many
partial reads as necessary to get to eof.)
>Oh, and even uses examples with stdin in the info page, so what...
Don't confuse stdin and a pipe. The behaviors of </dev/tape and cat| are
fundamentally different.
>Sorry, that all sounds like a bad excuse.
Oh well, I can't help the fact that you don't like it. I already
specified another program that will do what you're looking for.
>I think I can understand the programmers decission to use such
>simplistic buffer handling
Obviously you don't. It has to be like this in order to deal properly
with fixed block tape devices, which is what the program was written for
in the first place.
>but that is NOT the documented behaviour.
It is. You said, "read 200 blocks" and that's exactly what dd did. You
also said "read the input 1M at a time" and that's exactly what dd tried
to do. It couldn't, and indicated that in its output (that's what the
number to the right of the + is: the number of partial or truncated
reads/write). I don't see anything in the documentation to suggest that
you should expect a retry on a partial read to make each input block
equal to the specified input block size--a behavior which would break
some fundamental expectations of how dd should work. dd is the only tool
in the unix toolkit that I can think of offhand that deals with fixed
block records, and there's both a reason for that and a reason why that
makes dd behave differently from other programs.
>Bug apparently to kill the messenger. Do you really want to see this
>forwarded to TC?
If you must. If you want to open another bug as a wishlist with
suggested changes to the documentation you could do that also.
Mike Stone
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
