From unknown Wed Jun 18 23:16:44 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#59809 <59809@debbugs.gnu.org> To: bug#59809 <59809@debbugs.gnu.org> Subject: Status: dd: Summary discrepancy with iflag=fullblock if the last write would be partial Reply-To: bug#59809 <59809@debbugs.gnu.org> Date: Thu, 19 Jun 2025 06:16:44 +0000 retitle 59809 dd: Summary discrepancy with iflag=3Dfullblock if the last wr= ite would be partial reassign 59809 coreutils submitter 59809 Sworddragon severity 59809 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 03 18:32:54 2022 Received: (at submit) by debbugs.gnu.org; 3 Dec 2022 23:32:55 +0000 Received: from localhost ([127.0.0.1]:53942 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p1c06-0003NZ-D1 for submit@debbugs.gnu.org; Sat, 03 Dec 2022 18:32:54 -0500 Received: from lists.gnu.org ([209.51.188.17]:55630) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p1c05-0003NT-1g for submit@debbugs.gnu.org; Sat, 03 Dec 2022 18:32:53 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p1c04-0007dW-Qi for bug-coreutils@gnu.org; Sat, 03 Dec 2022 18:32:52 -0500 Received: from mail-vk1-xa33.google.com ([2607:f8b0:4864:20::a33]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p1c02-0004A3-O0 for bug-coreutils@gnu.org; Sat, 03 Dec 2022 18:32:52 -0500 Received: by mail-vk1-xa33.google.com with SMTP id b81so3831088vkf.1 for ; Sat, 03 Dec 2022 15:32:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=5mGI175ge0UVdWqwFmSf7VXKwHLPOFAgtYipTB7kNOM=; b=Ap3KPOc3XQ/JLQjNlNu9ZDcTLcwM+9YXEwtbQJnmBjiZbiK5A2RcC5LA7B9vSGmJz7 ZUjifZoxT30TO//InkL6yZ3gz6AcpcRdga4hizA8imJRY8AumfFL7Sjdo66/6w1XGNKi PzMie8X9ie1Q5kLrv0i3sZveuIzhesGS5mydb+T7Hj5gTBnETUFja7w5QGdKRDYNTXLF Lc4rf6UMjYJ5VUBGDYQh1EDPSLst1Z6S/q6ILYJdYVnhTj9Tqk0ET11wpvOTOkLUILs0 fNiO6JquEM3ggn3b6YluodGgim0JyPGuJEK6DRiA1cBVYVAM98DWZ3J6DWA4G+jaqXvZ 14xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=5mGI175ge0UVdWqwFmSf7VXKwHLPOFAgtYipTB7kNOM=; b=M+7qvBnd5OeUh7+apU2YAgxkkKsby+kzy1kOuwh+hQsy6TtV+lVlR5y5loGAjDdUSk Orb+ePpbetriinL/vUTBenZlQ6MfLZ4McLh9zytn9owcFDRK+05xojvUuc/9+BGQvzW8 OSX5Vfgv6adLTH60dIrNA3mWNqX07o8vydveREICojyRRSDYiaTL5D1uJ3JnymBvtuq0 DEwXjiV9Z5y3k7U1ZH0hln4zD+JR21OOUsXca8dJdFpk9/TsNj+5+XDs+R+3QtZKxwPz H+D0PeYhRnDOv6kNmMMawAfmnlT+NAn7/UwDahMxfggjmluqy3hZBw7IFt8bBVI7lx5j KxTQ== X-Gm-Message-State: ANoB5pmNDCK7uMxzoHm8PEgS5cA9XGPoFoYUhIehmLg5+nBV335b8E4G D9flnS31Qw5j8yIuZrcC7H9IBJCcBA2LJv1UiiwvrIcS3ORijw== X-Google-Smtp-Source: AA0mqf7RZUzKk1hCR/8SwPq7xfdIPbWPalqXc9w4Gg/NEJXPt7SGic+EL96WUGE7tdhgD0MiUmvampxaVk5EdaQ/CRE= X-Received: by 2002:a1f:b247:0:b0:3bb:ea0f:9330 with SMTP id b68-20020a1fb247000000b003bbea0f9330mr34254715vkf.4.1670110369175; Sat, 03 Dec 2022 15:32:49 -0800 (PST) MIME-Version: 1.0 From: Sworddragon Date: Sat, 3 Dec 2022 23:32:39 +0000 Message-ID: Subject: dd: Summary discrepancy with iflag=fullblock if the last write would be partial To: bug-coreutils@gnu.org Content-Type: multipart/alternative; boundary="0000000000004a5cb805eef4df64" Received-SPF: pass client-ip=2607:f8b0:4864:20::a33; envelope-from=sworddragon2@gmail.com; helo=mail-vk1-xa33.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) --0000000000004a5cb805eef4df64 Content-Type: text/plain; charset="UTF-8" Hi, I'm using Knoppix 9.1 (x86_64 environment) (from early 2021 - but this is the most recent version of it that is public available) with GNU Coreutils 8.32. I was overwriting a HDD and wanted to try out the iflag=fullblock option - despite not strictly needed for that special case but this shouldn't matter. Here is the output that I got (freely translated form german to english so some terms might be a bit off): root@Microknoppix:~# dd if=/dev/random iflag=fullblock of=/dev/sda bs=1M conv=fsync status=progress 320059998208 Bytes (320 GB, 298 GiB) copied, 5519 s, 58.0 MB/s dd: Error on writing to '/dev/sda': No sufficient disk space available on the device 305246+0 records in 305245+0 records out 320072933376 Bytes (320 GB, 298 GiB) copied, 5539.18 s, 57.8 MB/s (That the output from status=progress mismatches with the final result is due to bug https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51482 which should be already fixed so just ignore that) The summary tells me that 320072933376 Bytes have been written which does not match a multiple of bs=1M which implies my HDD has been fully overwritten with random data - which would also match the documentation for iflag=fullblock since it should never affect partial writes. However, the previous line tells me that 305245+0 records have been written which tells me that the last 352256 Bytes of my HDD haven't been overwritten with random data. So there is a discrepancy in the output where the second last line tells me "305245+0 records out" while the last line basically tells me "305245+1 records out" - which one is now true? So this issue seems to be a summary bug and in the worst-case also a dataloss bug. Edit: To test this further I did now a run of the same command just without iflag=fullblock and I got pretty much the same result (305246+0 records in, 305245+0 records out, 320072933376 Bytes copied). So this issue seems to be not related to iflag=fullblock - but the discrepancy in the summary still exists. In this run I would have expected to see "305245+1 records out" and I'm now curious again if my HDD has been fully overwritten or not. Maybe somebody can shed some light into this if something is indeed broken or if I just miss something that I can't figure out. --0000000000004a5cb805eef4df64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I'm using Knoppix 9.1 (x86_64 environment) = (from early 2021 - but this is the most recent version of it that is public= available) with GNU Coreutils 8.32.

I was overwriting a HDD and wan= ted to try out the iflag=3Dfullblock option - despite not strictly needed f= or that special case but this shouldn't matter. Here is the output that= I got (freely translated form german to english so some terms might be a b= it off):

root@Microknoppix:~# dd if=3D/dev/random iflag=3Dfullblock = of=3D/dev/sda bs=3D1M conv=3Dfsync status=3Dprogress
320059998208 Bytes = (320 GB, 298 GiB) copied, 5519 s, 58.0 MB/s
dd: Error on writing to '= ;/dev/sda': No sufficient disk space available on the device
305246+= 0 records in
305245+0 records out
320072933376 Bytes (320 GB, 298 GiB= ) copied, 5539.18 s, 57.8 MB/s


(That the output from status=3Dpr= ogress mismatches with the final result is due to bug https://debbugs.gnu.org/cgi/bu= greport.cgi?bug=3D51482 which should be already fixed so just ignore th= at)

The summary tells me that 320072933376 Bytes have been written w= hich does not match a multiple of bs=3D1M which implies my HDD has been ful= ly overwritten with random data - which would also match the documentation = for iflag=3Dfullblock since it should never affect partial writes.
Howev= er, the previous line tells me that 305245+0 records have been written whic= h tells me that the last 352256 Bytes of my HDD haven't been overwritte= n with random data.

So there is a discrepancy in the output where th= e second last line tells me "305245+0 records out" while the last= line basically tells me "305245+1 records out" - which one is no= w true?

So this issue seems to be a summary bug and in the worst-cas= e also a dataloss bug.


Edit: To test this further I did now a ru= n of the same command just without iflag=3Dfullblock and I got pretty much = the same result (305246+0 records in, 305245+0 records out, 320072933376 By= tes copied).
So this issue seems to be not related to iflag=3Dfullblock = - but the discrepancy in the summary still exists. In this run I would have= expected to see "305245+1 records out" and I'm now curious a= gain if my HDD has been fully overwritten or not.

Maybe somebody can= shed some light into this if something is indeed broken or if I just miss = something that I can't figure out.
--0000000000004a5cb805eef4df64--