public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Hashim Aziz <hashaziz@hotmail.com>
To: cygwin <cygwin@cygwin.com>
Subject: Re: [cygwin] DD bug fails to wipe last 48 sectors of a disk
Date: Tue, 23 Jun 2020 15:28:31 +0000	[thread overview]
Message-ID: <DB7PR01MB519396195ADB3E3E1217B22BD5940@DB7PR01MB5193.eurprd01.prod.exchangelabs.com> (raw)
In-Reply-To: <60bf1507-4edb-a03f-ec14-07e1ab7f0d94@cs.umass.edu>

I hadn't checked with 512 byte block sizes because of the amount of time it would have taken, but sure enough have just finished trying with bs=512 and no block size at all (so dd's default block size, which is either 512 or 1024) and although each wipe took over 24 hours, they did indeed wipe all of the sectors. So it seems that there's a bug with regards to how Cygwin handles the last block when a large (i.e. sane) block size is selected, and that this bug doesn't occur on actual UNIX-based systems.

________________________________
From: Cygwin <cygwin-bounces@cygwin.com> on behalf of Eliot Moss <moss@cs.umass.edu>
Sent: 20 June 2020 9:26 PM
To: The Cygwin Mailing List <cygwin@cygwin.com>
Subject: Re: [cygwin] DD bug fails to wipe last 48 sectors of a disk

On 6/20/2020 1:31 PM, Hashim Aziz via Cygwin wrote:
> To reproduce simply run the following command on a drive (obviously, this will irreversibly wipe all data):
>
> dd if=/dev/zero of=/dev/sdX bs=4M status=progress
>
> Both drives were attached via internal SATA (by way of a PCIE to SATA Host Bus Adapter).
>
> Cygwin was running in an elevated window as dd cannot run in Cygwin without administrator access, at least not on Windows 10 and not when dealing with raw disks. I was running Avast the first time I discovered this, and am currently running Windows Defender, so doubt that the AV is the cause of this.
>
> The hard drives are a Western Digital WD10PURX-64E5EY0 (Serial: WD-WCC4J6HX189U) and a Kingston SV200S3128G (Serial: 12BA315PKAWK).
>
> I just ran DD for Windows 0.6beta3 with variations of the following command:
>
> dd.exe if=/dev/zero of=\\.\PHYSICALDRIVEX --progress bs=4M
>
> ...and can confirm that the bug also manifests here, but in a slightly different way - irrespective of the disk or block size, it fails to wipe the last 176 sectors of the drive.

I was going to ask: even with block size 512 bytes?  But I guess you checked that ...

Regards - Eliot
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

  reply	other threads:[~2020-06-23 15:28 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-19 18:19 Hashim Aziz
     [not found] ` <1d1801d64677$bea56050$3bf020f0$@pdinc.us>
2020-06-20 17:31   ` [cygwin] " Hashim Aziz
2020-06-20 20:26     ` Eliot Moss
2020-06-23 15:28       ` Hashim Aziz [this message]
2020-06-23 15:29         ` Eliot Moss
2020-06-23 16:06         ` Nicholas Clark
2020-06-23 19:46           ` Hashim Aziz
2020-06-24 10:21             ` Andrey Repin
2020-06-25 12:08               ` Hashim Aziz
2020-06-25 13:25                 ` Brian Inglis
2020-06-28 14:34               ` Christian Franke
2020-06-28 17:50                 ` Jason Pyeron
2020-06-28 20:28                   ` Brian Inglis
2020-06-23 19:33         ` Brian Inglis
2020-12-29  0:46           ` Hashim Aziz
2020-12-29  2:41             ` Jason Pyeron
2020-12-29 17:54               ` Brian Inglis
2020-12-30  1:35                 ` Jason Pyeron
     [not found]                   ` <DB7PR01MB5193B13815933B913D11DDC2D5D20@DB7PR01MB5193.eurprd01.prod.exchangelabs.com>
2021-01-04 21:08                     ` Jason Pyeron
2020-08-04 22:42 ` Hashim Aziz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DB7PR01MB519396195ADB3E3E1217B22BD5940@DB7PR01MB5193.eurprd01.prod.exchangelabs.com \
    --to=hashaziz@hotmail.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).