From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) by sourceware.org (Postfix) with ESMTPS id 2DC79396ECBB for ; Tue, 23 Jun 2020 19:33:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2DC79396ECBB Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=brian.inglis@systematicsw.ab.ca Received: from [192.168.1.104] ([24.64.172.44]) by shaw.ca with ESMTP id nofOjCfeMng7KnofQjoDHQ; Tue, 23 Jun 2020 13:33:12 -0600 X-Authority-Analysis: v=2.3 cv=ecemg4MH c=1 sm=1 tr=0 a=kiZT5GMN3KAWqtYcXc+/4Q==:117 a=kiZT5GMN3KAWqtYcXc+/4Q==:17 a=IkcTkHD0fZMA:10 a=w_pzkKWiAAAA:8 a=ioyUOmMPAiA2c8Vb-UcA:9 a=QEXdDO2ut3YA:10 a=sRI3_1zDfAgwuvI8zelB:22 Reply-To: cygwin@cygwin.com Subject: Re: [cygwin] DD bug fails to wipe last 48 sectors of a disk To: cygwin@cygwin.com References: <1d1801d64677$bea56050$3bf020f0$@pdinc.us> <60bf1507-4edb-a03f-ec14-07e1ab7f0d94@cs.umass.edu> From: Brian Inglis Autocrypt: addr=Brian.Inglis@SystematicSw.ab.ca; prefer-encrypt=mutual; keydata= mDMEXopx8xYJKwYBBAHaRw8BAQdAnCK0qv/xwUCCZQoA9BHRYpstERrspfT0NkUWQVuoePa0 LkJyaWFuIEluZ2xpcyA8QnJpYW4uSW5nbGlzQFN5c3RlbWF0aWNTdy5hYi5jYT6IlgQTFggA PhYhBMM5/lbU970GBS2bZB62lxu92I8YBQJeinHzAhsDBQkJZgGABQsJCAcCBhUKCQgLAgQW AgMBAh4BAheAAAoJEB62lxu92I8Y0ioBAI8xrggNxziAVmr+Xm6nnyjoujMqWcq3oEhlYGAO WacZAQDFtdDx2koSVSoOmfaOyRTbIWSf9/Cjai29060fsmdsDLg4BF6KcfMSCisGAQQBl1UB BQEBB0Awv8kHI2PaEgViDqzbnoe8B9KMHoBZLS92HdC7ZPh8HQMBCAeIfgQYFggAJhYhBMM5 /lbU970GBS2bZB62lxu92I8YBQJeinHzAhsMBQkJZgGAAAoJEB62lxu92I8YZwUBAJw/74rF IyaSsGI7ewCdCy88Lce/kdwX7zGwid+f8NZ3AQC/ezTFFi5obXnyMxZJN464nPXiggtT9gN5 RSyTY8X+AQ== Organization: Systematic Software Message-ID: <1b13fde4-0834-cd8b-0673-c2b14bbaa372@SystematicSw.ab.ca> Date: Tue, 23 Jun 2020 13:33:10 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfJcP1yKDIBMnGDyHsCAldSVH8lmaaHKdIUBhGS1oxQKNzPbyb6+YGn4wmtiuoXxn8P2xfYMeeieCVXuVTrD5c0iKiHxes70HCmP5HV6x6xRT03jbHMWv O4dE0WqfzGsrBFwmO08lyNK0p7QciFjIQcbmA7sV/ay9Oeo2cKa1HNBM2FPK6GgxfFFnu45xiZVMew== X-Spam-Status: No, score=-10.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 19:33:15 -0000 On 2020-06-23 09:28, Hashim Aziz via Cygwin wrote: > 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 on behalf of Eliot Moss > Sent: 20 June 2020 9:26 PM > To: The Cygwin Mailing List > 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 ... I don't have the facilities to test, and there appear to be *NO* Windows documentation details on error condition handling, but my suspicion is that Unix reads and writes fail only *AFTER* reading or writing at the end of the device, but Windows reads and writes extents may be checked and failed *BEFORE* reading or writing any data near the end of the device. If the actual Windows error code returned is generic, Cygwin would need to pre-check the device size as Windows does, and reduce read and write sizes to the allowed maximum at the end of the device. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.]