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
