X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A8C623835C36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1629372437; bh=Sv0dCilUA/j2YmGLUIpCbLxOkkM6r+v2A3QXGIuKiQg=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=K+Vv3yrMM9aid/YIG7yJsw76EKl/A4FWU5huQRGIozPnfQrf5JPzfJq7ksrXbGNKO Nk1fR4egq4DpPTDFV0sf8MDoOANqcyzz93IbcRxntwSC10W08xa/Bhhr+FZIxJr2JZ bR/+TwRTdMperIdcBMY22ZOxqvf2gXZnPryAfY/4= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ADA30385AC1D Date: Thu, 19 Aug 2021 13:26:01 +0200 To: cygwin AT cygwin DOT com Subject: Re: Duplicates in /proc/partitions Message-ID: Mail-Followup-To: cygwin AT cygwin DOT com References: <9a770c83-62ef-6849-16e7-e6956f4d2fab AT SystematicSw DOT ab DOT ca> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:HLycLI+7ivE10bfk5dJ06jPq518pudfEB0vPuiPXB0KPj8B4A6i ABah+7WCu2wACYls0reDc4PqjvGoAILzE2EB85f4KHVUpgwTztr2vpMTHjr3HA3gaFPBT3i 8/f7pYBKJ2BZG7XT11n++KXCpFjAaYdbfPANcDyf8qiMw9geWF1xQOYIByehI/ZdSYB1FvM DEZI0xKXuqrRPBlvk6oMw== X-UI-Out-Filterresults: notjunk:1;V03:K0:UKQOus9FMJw=:BxaBFuOmSSKUdlbYfrPz7b h4W76OJbgingiQ3fc3748vC/zGBRu8tmS537Qg8OEUc74XRrb0l4YZoqYcT3PIfF/2v1vbdCk pMFmr4IFCcB15ZafNNjHz9HBB4gE2Iut7WSKbScKm/7uKcLpXm9BVL/VxyzsV1EZuL4BDaT5V rYe9QuSUtSyzeyQ/H1QjR3ZI7qZcj/1O4gqS5N8dzJOikzGjK6QpcDR13ZUp5j14F8UbaSYhH Pyl50YgSY7L4kLmXiCKc6kuQ1ulx2uZD1PXMTSdSd6Xg3qm2x+r4lSapvQpwV2oLqGpMwQuVC dQBR4HOViNWm31OLV55VZhoap24MTTe51KgfYk9va/EGCtbn7TSj3SLbJChT0KMbiw4XFEw1Z zeMRRNbLI167RnvE4bkZ83SW0dAH78pRskrcS9ovq3xfhryCvS2HrpK4+6Eo44gHZ8Y5ZfH7Q 9Q67F7AvB8mQzxgGC1gwRLJ6+i7Rs0pUQSu64FiNmqEIRumle9yq2/ciY16uGoCCNw0N9lMdn l1guWTpwbm3jZbzi9LxL7xt8eFQ8av+e2IMVNvcov+dpWcBmB3k9q59EpdNOGPXu6qzm4hQA1 +TO3NFrt+A/HIKlqcAt4NCbiEWvIPjz6CCXpdyRTv6qBWqfMvXblpybj15+pV1RH5jDysxbJ5 vMFBhb7uJV99ifhqX+gBzEs7FdjWW9fnVahVsUeFWvC6RT54VFnqFzzBpF/q4D8spT3thPVuk Ey2HPz0sG8qKPpAS67qI9moLImGPsp/l5W1xsctp6+kwg6/uIZ/v5shelogRtY/+Sco6UYWGT nsFB4K+vY6pMWDUbRMAL2QBqkbA08uNEZs332dNfV1O6zW2G4C7RF9fOpwLrZI9mt+nDsXkhh HpTPjCzaqQ4/voq/64mg== X-Spam-Status: No, score=-100.2 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Corinna Vinschen via Cygwin Reply-To: cygwin AT cygwin DOT com Cc: Corinna Vinschen Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" On Aug 19 12:03, Corinna Vinschen via Cygwin wrote: > On Aug 18 18:36, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > > > And I just confirmed that if I print the context right before NtOpenFile(), and just do > > > the "continue", > > > > But then I also tried this: I removed the "continue" before "NtOpenFile()" and allowed it to proceed, > > but I moved NtClose(devhdl) right after the "printf" statement (that we were tweaking), and > > inserted the "continue" there, so it does not proceed with enumerating of the partitions. > > And so again, I got the output that matches my disks without the duplication. So this actually > > exonerates NtOpenFile() :-) > > [...] > > Unfortunately I can't reproduce the issue. I created a couple of > virtual drives and added them to my W10 and my W7 VM, but to no avail. Never mind. I now can reproduce the problem at will. The trick is to create objects inside the \Device directory while the loop iterating over the directory is running. As shitty as it is, a NtOpenDirectoryObject/NtQueryDirectoryObject/NtClose loop is not working atomically. If a new object is inserted into the dir preceeding the currently handled entry (which, on a reliable system should *never* occur), the entry is moved by one, and the next NtQueryDirectoryObject call returns the same object again. Windows never disappoints when one is looking for really ugly problems. The good news is that NtQueryDirectoryObject is also capable to take a big buffer and return as much entries as fit in in the buffer. I'll give it a try now in the vain hope that this way to call NtQueryDirectoryObject returns reliable, atomic-like results... Corinna -- 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