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
Precedence: list
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
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