https://bugs.winehq.org/show_bug.cgi?id=46697
--- Comment #11 from qsniyg qsniyg@mail.com --- (In reply to Nikolay Sivov from comment #10)
What's the status of this? If NtQueryDirectoryFileEx() is really needed it's easy to add and use it for NtQueryDirectoryFile(), but does that solve the problem? If this library intercepts calls to NtQueryDirectoryFileEx() maybe we'll also have to use where we now we're using NtQueryDirectoryFile().
It's not needed, unless something in USVFS changed recently (and according to a quick look at the commit log, no). It was a red herring from the beginning, as USVFS prints an error, but will work just fine without it (NtQueryDirectoryFileEx is only implemented on later versions of Windows 10, but USVFS works on Windows 7 as well).
There are apparently some issues with USVFS and later versions of wine (haven't had the chance to test lately, it _could_ be due to wine calling the functions directly, rather than the syscall thunks - as was the case with wine-staging before 5.0), but it's almost certainly not due to NtQueryDirectoryFileEx. Earlier versions of wine (4.21+) worked fine, as both of of the patches needed to get it working got upstreamed (an earlier version of the patches are linked in #4).
That being said, as you said, they had to add that function because NtQueryDirectoryFileEx was being called instead of NtQueryDirectoryFile in later versions of Windows 10. So if wine wants to emulate the later versions of windows 10, this can be done. However, it's not necessary to get USVFS working.