protonscr

Merge USVFS patch

wineclosed
ValveSoftware/wine#67 · opened 2019-09-13 by qsniyg · updated 2019-12-01 · 5 comments · github
Qqsniyg 2019-09-13 github

https://gist.github.com/qsniyg/ec21d68f9407991a1043a71fa6ffd4cf

This would allow ModOrganizer 2 (probably the most popular program to mod Skyrim/Fallout) to work under Proton.

The patch is mostly just a point of reference (hence why the check was commented out instead of removed), so you'll probably want to implement it your own way.

Researching more into the check however, I believe the check present in wine actually doesn't follow Windows's behavior at all, because USVFS will consistently return only one entry when iterating through the virtual filesystem with NtQueryDirectoryFile, and Windows accepts it. So I believe any regressions stemming from removing the check would rather be a separate inaccuracy in wine, rather than the check being at fault (so far, I haven't noticed any regressions).

Reddit thread explaining about the patch: https://www.reddit.com/r/linux_gaming/comments/d3493y/i_got_mod_organizer_2s_usvfs_running_under_wine/

Aaeikum 2019-09-13 github

Per that Reddit thread, FILE_OPEN_FOR_BACKUP_INTENT will become unnecessary in an upcoming version of the software.

For the other chunk, I think we'll need to understand what that check was trying to do before just removing it. I'm not immediately familiar with those APIs, myself.

Qqsniyg 2019-09-13 github

@aeikum

FILE_OPEN_FOR_BACKUP_INTENT will become unnecessary in an upcoming version of the software

Right, however I believe this does more closely mirror Windows's behavior regardless (at least according to the Windows USVFS log files I was provided). From a quick grepping of the source, it doesn't appear the flag will do anything in Wine, so I believe it's relatively side-effect free.

I think we'll need to understand what that check was trying to do before just removing it

I agree.

My understanding of this check is that it checks if the size of the buffer filled by NtQueryDirectoryFile is less than the total size of the buffer, minus the size of the largest possible entry (i.e. it's a rough check to ensure the NtQueryDirectoryFile has filled the buffer as much as possible). However as I wrote above, Windows's implementation of FindFirstFileEx seems perfectly happy to accept an underfilled buffer with only one entry.

My guess is that this is an optimization to avoid calling it NtQueryDirectoryFile again, as it is a relatively expensive call (interacting with wineserver and at least 3 syscalls).

MMaxXor 2019-10-04 github

Just ran into the same issue trying to mod Skyrim SE. Would be very helpful to have this patch included once all details for the removal of that check are cleared up.

Qqsniyg 2019-10-05 github

For the record, I've since submitted the patches to wine-staging:

https://bugs.winehq.org/show_bug.cgi?id=47832
https://bugs.winehq.org/show_bug.cgi?id=47833

However, it might not be merged due to the realname policy (which is for legal reasons as far as I understand, which I completely respect). That being said, the patches are public domain, so if someone else wants to submit them with their own name, you're free to do so.

(The lack of real name is for personal reasons, not legal -- I haven't reverse-engineered any of Windows' source code, neither have I even developed this patch with the aid of a Windows box, I only relied on the MO2 team for Windows-run logs they provided of USVFS)

Qqsniyg 2019-12-01 github

As of wine 4.21, this is upstreamed

Upstream links