X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D1BA73858039 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1629387560; bh=pG4aKN7T2RvxfNlG8wmYM/Tbpz8EYYmE2xMLw2tsu/k=; 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=dUSpZngOYv3BaP57lCVJTH/8t1L/adwlY20Xk0r7nyZHW3J8sHBgYb8M4Cpu5MSL7 ypZk+5uVSR/uJmL3GzhHFx62uMnw+K4FNC64iZuXJxeccHw32bDekk32Fv/3Fz0NWv 9eA+tfBKxiM16C3PHMGj9fOX+/0rNK9QRVu3c0XY= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C262238515DD Date: Thu, 19 Aug 2021 17:37:38 +0200 To: cygwin AT cygwin DOT com Subject: Re: Duplicates in /proc/partitions Message-ID: Mail-Followup-To: cygwin AT cygwin DOT com References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:T94p7Ef5+wbwibZfNqO5diYaokW2COrjpzTMDTWS/VWOpO65TyC 7S9kFcLPl8oEIa13NHK3JbSfl0kpzqaP6rYnQYMhVHVrZIkDV+x1/jSoZJhyTDjnxEfE2lg yWZcRkenzYFD5o6CfqHMb9eWC1hJihnJpMFT81eahdQtmUS6hYZnPR/XbgMJnbzyHlbozwb LgRjIiHGj9ubBqgn6Z67g== X-UI-Out-Filterresults: notjunk:1;V03:K0:ijQ2JoxfZ0A=:YiHtQqbQAMyEwdqKQECLEH zrDYI9puJOe0E+yihXhorHXMe+d+ZwoTMfqKP7b4hfUMlemOD4tDqmKXJ563P3Y5s/F9NFLsk bxG+FBtmupAqqtEegA3sjcp8hSUEaLHgP40byAiekKt3y0AxE2aXxwi/iPe0l5dzmgNnZLHK+ PisY5txXo9KHgW8jQk0WS+8E9KAuP8H2q6J9mxBywcemM3fVkKE+VIvaJe5+IXYHgR5/azVYJ 3kCzHjPR7jrAUsUS3xVg0vCrxeRPceVdkQ2O42bNqYJBUrx+QVi3dysJXjTMY7Ea/q337hCpS HGTMpnBWC2jLD+KoqQKTLR3r99aEiF1607hHGUG1EPDNhWzlJd5rSL+mxaWHCVzZg7pN/dn1v xVVywL4eDpO9qUJ8jjqfc4sTlJ+sBT7jUZK+KCuq9/xn+XE/5wSNkCrELHqQB4N35N33fEACP DblnUTfIcO9BMOR8f/SMQi/z9YHJP2htWUpD/sVL/0HBm/eh4onTOaAJduLxXFCI63t3+8Yvk W06/yFKCSyQ1F/QidzLvk0XSFdV0K2jVPYmUyE+MHsypUlMG4fV6ApWSy19aDEMNh3XaqZbsh 9RSf6YPhiNcVgVaQeXAYgdYGWjHz6CXwGVmMZTm6iiCgJNcYe4ShLLzviaHb43f8TDrBiFP5l eTT3c0YgfGSKnj1LtNWdbtif++o7X+H+1w/KNJZxunimalKMhGIOx3LsWPNSOod5Q4hE5F4iU 4LDV9bnUXS0maSa9BxRRzH+DWIb1mx50flb+wXFq4Wo+5cvZQi2ToUM73ULt5fIij942016pA ChhnEKl7Q0U/QePEOnShZKLX++nb3010yo0iJenoMD6DBqd3LmuZG3fxQSlwUvAgMmxpDHSYR 8P9x61KNLTYkgGgQysCg== 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, 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 15:15, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > > > 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. > > Very interesting... What would be inserted in the directory on my machine, > in between the calls in that original test program? It was the only one > running there, explicitly, I mean... This also occurs all the time on my system. It seems to be quite normal in fact. That's the only action explaining that the same entry gets different context values when running the loop multiple times. Observing the changing context value was what gave me the idea to trigger this by creating a symlink to the \Device dir at a certain iteration in the loop, and that in turn allowed me to reproduce the problem. > And exclusion of the loop of partition > enumeration seemed to cancel the insertion? Not as such. Probably this just changed the timing. > one exhibition of the problem, and the other one on my machine here is > different, and not well understood, but with the same side effect, > unfortunately. > > > Anyway, would you mind to test the below new proc_partition.c as well > > Looks promising indeed! No duplicates: > > $ ./proc_partition > bytes_read = 34346, context = 461, status = 0x00000000 > major minor #blocks name win-mounts > > 8 0 500107608 sda (461, Harddisk0) > 8 1 102400 sda1 > 8 2 488280064 sda2 C:\ > 8 16 1000204632 sdb (461, Harddisk1) > 8 17 1000202240 sdb1 D:\ > 8 32 1000204632 sdc (461, Harddisk2) > 8 33 1000202240 sdc1 G:\ > 8 48 1000204632 sdd (461, Harddisk3) > 8 49 1000202240 sdd1 I:\ > 8 64 234431064 sde (461, Harddisk4) > 8 65 234428416 sde1 F:\ > DeviceIoControl (Harddisk5\Partition0, IOCTL_DISK_GET_PARTITION_INFO{_EX}) 5 8 80 0 sdf (461, Harddisk5) > > > as the latest snapshot I just uploaded to https://cygwin.com/snapshots/? > > I'll have to do that later, not now. But I'll report once I have a change to try it out. Great! Looking forward to it. Thanks, 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