From: "Jason Pyeron" <jpyeron@pdinc.us>
To: <cygwin@cygwin.com>
Subject: RE: [cygwin] Re: DD bug fails to wipe last 48 sectors of a disk
Date: Mon, 14 Sep 2020 13:09:29 -0400 [thread overview]
Message-ID: <019c01d68ab9$cf4f1e60$6ded5b20$@pdinc.us> (raw)
In-Reply-To: <DB7PR02MB39966971C7E65CE5B5722157E7230@DB7PR02MB3996.eurprd02.prod.outlook.com>
> 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.
next prev parent reply other threads:[~2020-09-14 17:09 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 [this message]
2020-09-14 17:58 ` Thomas Wolff
2020-09-16 8:19 ` Hamish McIntyre-Bhatty
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='019c01d68ab9$cf4f1e60$6ded5b20$@pdinc.us' \
--to=jpyeron@pdinc.us \
--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).