X-Recipient:	archive-cygwin AT delorie DOT com
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.3.2 sourceware.org 20A223857C62
Authentication-Results:	sourceware.org;
	dmarc=none (p=none dis=none) header.from=towo.net
Authentication-Results:	sourceware.org; spf=none smtp.mailfrom=towo AT towo DOT net
Subject:	Re: [cygwin] Re: DD bug fails to wipe last 48 sectors of a disk
To:	cygwin AT cygwin DOT com
References:	<DB7PR02MB39967687CBFD5033B6DDE01AE7230 AT DB7PR02MB3996 DOT eurprd02 DOT prod DOT outlook DOT com>
	<CACoZoo1cwtVvGsk-WL9utaWWRXSDuHOs8aeiY5_gq-g7Ez9Ucg AT mail DOT gmail DOT com>
	<00e301d68ab4$b0ea4da0$12bee8e0$@pdinc.us>
	<DB7PR02MB39966971C7E65CE5B5722157E7230 AT DB7PR02MB3996 DOT eurprd02 DOT prod DOT outlook DOT com>
	<019c01d68ab9$cf4f1e60$6ded5b20$@pdinc.us>
From:	Thomas Wolff <towo AT towo DOT net>
X-Tagtoolbar-Keys:	D20200914195851860
Message-ID:	<4dbc7876-9992-1ac2-2064-6db5207d676c@towo.net>
Date:	Mon, 14 Sep 2020 19:58:51 +0200
User-Agent:	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
	Thunderbird/68.12.0
MIME-Version:	1.0
In-Reply-To:	<019c01d68ab9$cf4f1e60$6ded5b20$@pdinc.us>
X-Provags-ID:	V03:K1:FXPWk+CLiyQrwsQNnt1wto7hSZPMRInFRs5MtclDRH18hgmSTBA
	Q5IbUoZamG3hvGGd/ghuwCLvianM1xgc8k5DIlfsOxx+PxSzVV6WsvR5Fn2itnFve2BiINl
	/vjbjiQhuFSZIetqmdWwi4Amj9Igutx2MwyeJd7Grq/MiZQ1xFe/omQxT/SPH+SC6ZVcFD/
	fbfX7CL3VhQYWMqcUlFJg==
X-UI-Out-Filterresults:	notjunk:1;V03:K0:+NUjhblNO5M=:dU980bxa3siprcf5W2Ozv0
	OCEHP8/Z/myZ2jMl7OIxHxEvjYUsDusOrTPhy+BNA1+GpWxNCu1sryzBxuI1AWrbLuku844L0
	De9eNj00w+J4/ywH+4MLgCI/xqeu3wiiVBy1lHaPgAAuk5idmsqfziEGvHaysdpqTKO8s1YWD
	1gmICW+5d6ozuhRnpBFWsDrftE8uLIrga+s6J/xPhRIQ1t4yJ19Gdra0csqjPXGKiWdm3H9Dy
	DsUXBGvnL+W8pdIzpaSdK2tzl+qP974a7seFj3CveeHwQYzF0pkSkT8ion0ks9f586EGCI8rL
	dkikNC6svYa1F2APb+xPbWEZqlB7NWwrYlSbX+WVSsjY+44f6p7P4Ep2D3NRz9BSJxE2ULwlp
	1HaqMqMAk8e/0yf4ZZqFNA/b2yGIF7uieQcE67NEbPrIrZEs/ppdOFmzkoI6GetWJUfT0pOhq
	cvKbKHj++vrOGgyQsbad4hM5EQOcjV5rsbVYABUNBVm4rYEYfnUC7EZI/acPJhf7TwMlpzheI
	nATobbrR6oOP2UMcpful9ruTPw1cKEb2jjeV2Niiaf57EdxXtdaYGIoub9KBlQOOQ5N+Pr2KF
	nnftxSgoIG73GWgyIuw0ONsHoNZX+c3Ykh2HtZsWdVIneESjpbU64ehUtZNe6niRDy8vWRAre
	+C+sjUEEJmUZmP2gBcU1T0VoyiDro+AYe1ETANGmkp9sbph2Tr01+D013+MkjNiE50aAAds/j
	nP5Gzks56aWNIAZ2n8emB7n5yHujJp7YQ+8LDZKNEns3UZX1Pqn7VwpWnYGu9SE9ZjUAbjzTb
	Xp8c+zp3XZ2U48LJgvjjCy/fjRVQ2+rrNQ4yx33z1sPwoVCUrkruGjJRWibbBKibJXUPQPG
X-Spam-Status:	No, score=1.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
	KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_ABUSEAT, RCVD_IN_DNSWL_NONE,
	RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE,
	TXREP autolearn=no autolearn_force=no version=3.4.2
X-Spam-Level:	*
X-Spam-Checker-Version:	SpamAssassin 3.4.2 (2018-09-13) on
	server2.sourceware.org
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Errors-To:	cygwin-bounces AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces AT cygwin DOT com>

Am 14.09.2020 um 19:09 schrieb Jason Pyeron:
>> 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.
Where in the code is that handled? Wouldn't it be easy to limit the 
count according to the disk size as a workaround?
--
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

- Raw text -