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 <cygwin-boun...@cygwin.com> on behalf of Eliot Moss > <m...@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 ...
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.] -- 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
