From: Hamish McIntyre-Bhatty <hamishmb@live.co.uk>
To: cygwin@cygwin.com
Subject: Re: [cygwin] Re: DD bug fails to wipe last 48 sectors of a disk
Date: Wed, 16 Sep 2020 09:19:24 +0100 [thread overview]
Message-ID: <DB7PR02MB39968B8E56858E3432AF5639E7210@DB7PR02MB3996.eurprd02.prod.outlook.com> (raw)
In-Reply-To: <019c01d68ab9$cf4f1e60$6ded5b20$@pdinc.us>
[-- Attachment #1.1.1: Type: text/plain, Size: 2050 bytes --]
Ah good, thanks for clarifying this for me. I don't think my program
will be affected by this bug.
Hamish
On 14/09/2020 18:09, Jason Pyeron wrote:
>> From: Hamish McIntyre-Bhatty
>> Sent: Monday, September 14, 2020 12:34 PM
>>
>> On 14/09/2020 17:32, Jason Pyeron wrote:
>>>> -----Original Message-----
>>>> From: Erik Soderquist
>>>> Sent: Monday, September 14, 2020 11:55 AM
>>>>
>>>> On Mon, Sep 14, 2020 at 11:45 AM Hamish McIntyre-Bhatty via Cygwin wrote:
>>>>> Was this ever resolved? I could have sworn I saw some discussion about
>>>>> this but I can't find it in the archives.
>>>> I still have the thread in my local email; a couple viable work
>>>> arounds were provided, but the issue's root cause is on the Windows
>>>> side, so I believe the only real route to a true fix would be via
>>>> Microsoft altering their code.
>>> When accessing with proper (aligned) block size and count I do not encounter the problem - happy to
>> test again.
>>>>> It might also affect ddrescue, I feel.
>>>> I believe you are accurate in this feeling.
> (next time, please attempt to bottom post on this mailing list, moved it where it belongs)
>
>> Could you perhaps try with ddrescue for me please (also has a block size
>> option)? I could try and reproduce myself but without the email thread
>> that will be a challenge.
> Yes, I observed the same result with ddrescue before (bad input = bad behavior, good input = good behavior). The issue, as I have observed it, is if Windows is asked to write a string of blocks, past the end of the drive it will silently fail and not write some of those block BEFORE the end of the drive.
>
> If block size (bs) is a multiple of 4096 (or 512 for most drives) and the count * bs = drive size exactly (as reported by windows) no error.
>
>
> --
> 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
[-- Attachment #1.1.2: 0x87B761FE07F548D6.asc --]
[-- Type: application/pgp-keys, Size: 3235 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2020-09-16 8:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-14 15:44 Hamish McIntyre-Bhatty
2020-09-14 15:55 ` Erik Soderquist
2020-09-14 16:32 ` [cygwin] " Jason Pyeron
2020-09-14 16:34 ` Hamish McIntyre-Bhatty
2020-09-14 17:09 ` Jason Pyeron
2020-09-14 17:58 ` Thomas Wolff
2020-09-16 8:19 ` Hamish McIntyre-Bhatty [this message]
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=DB7PR02MB39968B8E56858E3432AF5639E7210@DB7PR02MB3996.eurprd02.prod.outlook.com \
--to=hamishmb@live.co.uk \
--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).