https://bugs.winehq.org/show_bug.cgi?id=47833
Bug ID: 47833 Summary: FindFirstFileExW seems to be missing FILE_OPEN_FOR_BACKUP_INTENT flag to NtOpenFile Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs@winehq.org Reporter: qsniyg@mail.com Distribution: ---
When running USVFS (through ModOrganizer 2), its hooked version of NtOpenFile checks for the FILE_OPEN_FOR_BACKUP_INTENT flag to see if the function calling it is FindFirstFileExW.
Under Windows, this apparently works as expected, but wine doesn't pass the flag, causing USVFS to fail injecting directory listings. Adding the flag allows USVFS to work properly.
I haven't tested this under windows, so I have no way to verify if the flag only gets set for some arguments sent to FindFirstFileExW and not others, but since USVFS has been known to work for many different programs, I would personally assume that the flag is always set.
https://bugs.winehq.org/show_bug.cgi?id=47833
qsniyg qsniyg@mail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |qsniyg@mail.com
--- Comment #1 from qsniyg qsniyg@mail.com --- Created attachment 65341 --> https://bugs.winehq.org/attachment.cgi?id=65341 Set FILE_OPEN_FOR_BACKUP_INTENT
https://bugs.winehq.org/show_bug.cgi?id=47833
qsniyg qsniyg@mail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |leslie_alistair@hotmail.com | |, z.figura12@gmail.com
--- Comment #2 from qsniyg qsniyg@mail.com --- CCing Alistair and Zebediah as https://wiki.winehq.org/Wine-Staging_Development suggests, to have the patch considered for wine-staging.
As I haven't done any testing on a Windows machine, this patch could be incorrect, which is partly why I'm submitting it to the staging branch instead.
From looking into wine's source code however, I don't believe this will cause
any regressions from wine itself, as the flag appears to be mostly ignored. Where I believe where regressions could happen (if this doesn't match windows's behavior) would be if a different program needs to hook NtOpenFile.
https://bugs.winehq.org/show_bug.cgi?id=47833
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |4.17
--- Comment #3 from Zebediah Figura z.figura12@gmail.com --- Sounds reasonable to me, though I'm inclined to say that regardless of testing it may be upstreamable directly. While I don't think it's [legally] safe to test what values Windows passes to NtOpenFile(), it's probably reasonable for us to alter behaviour in such a way if it's shown to improve programs.
Moreover, MSDN says that FILE_FLAG_BACKUP_SEMANTICS must be used to open a directory handle [1]. So it may be worth testing whether a similar restriction applies to NtOpenFile(), and, if so, it'd be even easier to justify adding that flag.
[1] https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-create...
https://bugs.winehq.org/show_bug.cgi?id=47833
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |ee266aba74809b0fb4833f2d276 | |2d3c687be4dd0
--- Comment #4 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Thanks.
Fixed by https://source.winehq.org/git/wine.git/?a=commit;h=ee266aba74809b0fb4833f2d2...
https://bugs.winehq.org/show_bug.cgi?id=47833
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #5 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 4.18.
https://bugs.winehq.org/show_bug.cgi?id=47833
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |4.0.x
https://bugs.winehq.org/show_bug.cgi?id=47833
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|4.0.x |---
--- Comment #6 from Michael Stefaniuc mstefani@winehq.org --- Removing the 4.0.x milestone from bug fixes included in 4.0.4.