From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) by sourceware.org (Postfix) with ESMTPS id 20A223857C62 for ; Mon, 14 Sep 2020 17:58:53 +0000 (GMT) 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@towo.net Received: from [192.168.178.45] ([95.90.245.244]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.167]) with ESMTPSA (Nemesis) id 1Mdevh-1kqfP82ZSz-00Zh1t for ; Mon, 14 Sep 2020 19:58:51 +0200 Subject: Re: [cygwin] Re: DD bug fails to wipe last 48 sectors of a disk To: cygwin@cygwin.com References: <00e301d68ab4$b0ea4da0$12bee8e0$@pdinc.us> <019c01d68ab9$cf4f1e60$6ded5b20$@pdinc.us> From: Thomas Wolff 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> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2020 17:58:55 -0000 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?