Linux-Wine USVFS compatibility thread

[jarrard]

OP Update: Current MO2 via WINE status;

(refer to end thread for current status)

At this point in time MO2 mostly works with wine5/staging5, people will experience odd problems where MO2 will fail to load the VFS+EXE (tools/game) randomly and need to restart MO2.

These issues are likely some odd permissions failure happening with WINE and could even be due to me using NTFS for these games/files.

I intend to upgrade to straight EXT4 partition in the future (waiting on new NVMe) and will be able to test under native conditions then.

NOTE: Some window managers will cause semi-messed up font (ie. XFCE)

The problem

At the moment Mod Organizer 2.1.1 standalone install appears to work find under Wine 3.8 Staging (and other versions) without any need for .net installation, however the usvfs component appears to not mount the files correctly. I can't quite determine whats going wrong but the console seems to suggest the usvfs is at least loading.

Note: V2.1.2 breaks Linux compatibility, as always is a wine bug but that doesn't mean changes made can't be done in a wine friendly manner and still do what they need to do.

Environment

• Mod Organizer Version : 2.1.1
• Desktop OS/version used to run Mod Organizer: Linux Antergos Wine 3.8++

Details

Link to Mod Organizer logs

USVFS

The log files appear to be all empty, I guess it never initialized so doesn't log things.

MO Interface

mo_interface.log

I will try and obtain those log files, no idea where they could have gone too unless its a specific option somewhere?

PS. Fallout4/SkyrimSE give 50-70fps at 4k and high detail under DXVK and wine, its 100% worth getting working under Linux now! (and script extenders work, with patch)

[jarrard]

Yeah, however when copying this mod directly to the mod folder gives this SKSE output and basically sits there forever, SSE never starts so perhaps Fuz Ro D-oh is broken? SSE eventually closes. Maybe I should test 1 more, lol

UPDATE: Ok PrivateProfileRedirector.dll loads correctly via steam, I'll test it via MO2 to see if it gives same mod not found error code.

From within MO2 (via steamplay): couldn't load plugin D:\SteamLibrary\steamapps\common\Skyrim Special Edition\Data\SKSE\Plugins\PrivateProfileRedirector.dll (Error 126)

So guess that's confirmed.

[Silarn]

The 1.7 version should work with the latest SKSE64 and SSE, which I assume is what you're using. I don't use that particular mod myself, but I do have several working (inside Data, via MO2). .NET Script Framework + IFV, FISSES, moreHUD, PapyrusUtil, PrivateProfileRedirector, Papyrus Extender, RaceMenu, and SSE Engine Fixes.

I'd double check what the error is with them installed into MO2, but I don't have access to that machine right now.

[jarrard]

The 1.7 version should work with the latest SKSE64 and SSE

Yeah I know, I downloaded it on Dec 3rd, but its not working for me, well it loads but stalls SKSE64 and SSE won't start. (process closes by itself after a couple mins)

Perhaps you can drop Fuz Ro D'oh into your Plugins folder and check SKSE log file to see if it loaded correctly.

[qsniyg]

@jarrard I just tested with F4SE, PrivateProfileRedirector and MCM load fine for me (vanilla wine 4.21) with USVFS, and I don't have the F4SE folder in the real Data folder. Can you reproduce this issue with a game other than SSE? I don't have it to test, sorry.

@MagicRB Could you let me know which DLLs you tested that didn't work?

[Karandra]

PrivateProfileRedirector wasn't updated to latest version of SKSE64 and F4SE but it's version independent anyway.

Q: There is new version of Fallout 4 and/or F4SE, can I use this version with new game/F4SE version? A: Redirector itself doesn't need Script Extender to function. The only thing that depends on F4SE is overriding of "RefreshINI" console command to reload files from disk to update cached INI files. If you load Redirector without F4SE or with newer or older version of F4SE the Redirector will not override "RefreshINI" but still will function as usual. So you can use this plugin with any game and F4SE version.

If you absolutely need "RefreshINI" command to work with this plugin and I haven't had time to update it, you can disable Script Extender version check in PrivateProfileRedirector.ini file. Open it, find option AllowSEVersionMismatch and change its value to 1.

[MagicRB]

@qsniyg PrivateProfileRedirector, MCM, Better Console. None of them would load

[qsniyg]

@MagicRB Which flavor of wine did you use? Vanilla or other? I know that there were issues with other flavors of wine (this was before this issue was reported).

[MagicRB]

Vanilla, wine-5.0-rc1 staging

[cyro666]

@jarrard How have you managed to run the game with MO2 through Proton? If I launch MO2 with protontricks from the MO2 directory with: protontricks -c "cd $(pwd); wine ModOrganizer2.exe" 489830 I can get MO2 running from the Skyrim proton prefix, but it will complain steam is not running (despite the fact that it actually is). If I try to launch the game with "run SKSE" from MO2, nothing happens.

Seems like the native Steam and MO2 from the proton prefix aren't working well together? Or maybe it's because I'm using the Gloriouseggroll version 4.21-GE-2...?

[Silarn]

Well, in this case MO2 is expecting steam to be running as a Windows process, which it isn't. You should be able to tell it to ignore that particular warning.

[jarrard]

Steams add non-steam game to library can be a bit glitchy at best but that is how I have MO2 running through the steam library menu. You need to fix the link however so ModOgranizer.exe is in the launch options also (some odd bug with non-steam links only opening up folder explorer).

To make things even more simpler for me I got the game ID number generated for MO2 and just made it a symlink directly to the SSE game ID in compatdata folder. Hope that all makes sense.

However I'm not sure if NXM links via browser are behaving correctly atm so that you will need to tackle yourself.

As for testing Fallout4 to see if the DLL's load with that, I don't have it installed at this time but might be able to get around to testing it later on. Means downloading and setting it up again, surely someone else with FO4 AND SSE can test&compare dll loading via MO2 ?

protontricks -c "cd $(pwd); wine ModOrganizer2.exe" 489830

Using wine to launch MO2 is probably most of your problems. Just use Proton script directly.

STEAM_COMPAT_DATA_PATH="~/.steam/debian-installation/steamapps/compatdata/MO2IDorSSEID/" ~/.steam/steam/compatibilitytools.d/Proton-4.21-GE-2/proton run /MO2/ModOrganizer.exe

[qsniyg]

@MagicRB Could you try with just vanilla wine instead of wine-staging?

[MagicRB]

Sure, I'll give it a try today. (Today means in the next 6 hours)

[MagicRB]

@qsniyg It's working on winehq-devel, so normal wine, but 5.0-rc2. So some regression in staging, someone should report it but I have no clue how.

[jarrard]

I think staging has a git hub issue tracker? maybe I'm wrong. I sure hope this gets fixed sometime. I suspect its also a issue with proton & proton-GE

[qsniyg]

@jarrard So I've started to test it, and by checking through both the wine and the wine-staging usvfs logs, the issue is actually rather strange. Both wine and wine-staging are actually fed the un-redirected path for almost all LoadLibrary calls (except for the initial PrivateProfileRedirector one). However, while wine can load it properly (since LoadLibrary calls NtOpenFile, called by the open_dll_file helper), the usvfs log for wine-staging is actually different in many ways, for some reason. The issue roots in the fact that NtOpenFile isn't redirected when calling LoadLibrary for wine-staging (although it is redirected in other portions of the log, just not when LoadLibrary calls it), while it is hooked for wine. I'm not sure what the root cause of it is, whether it's because for some reason, LoadLibrary calls an unhooked version of it, or if usvfs somehow fails to find a redirect path for it.

After a bit more testing, the issue is either that LoadLibrary calls an unhooked version of it or there's some kind of error.

[jarrard]

Well this first got patched in Wine 4.18? How did it work with Staging 4.18 back then? was it still broken or is this something new staging has done I wonder.

There might be a way to narrow down the patch that directly affects this issue by patching wine with staging patches gradually until failure point. I'd do it with wine & staging 4.18 or whenever the fix first appeared in the wild.

Unfortunately I'm no master at this kind of patching, I struggle enough with bisections but if push comes to shove I guess I will do a investigation sometime into the issue.

Another thing to consider, is it worth using Wine Staging for SkyrimSE or FO4? do they benefit from staging patches at all? either way this issue should definitely be reported to the winehq bug tracker so the staging guys (I think they are merged in with winehq team now) know about the regression behaviour between wine and staging.

[qsniyg]

@jarrard It didn't work properly in wine 4.18, since only one of the two patches were present (it's actually quite possible that some SKSE setups didn't work under vanilla 4.18 either, for entirely different reasons).

There might be a way to narrow down the patch that directly affects this issue by patching wine with staging patches gradually until failure point

I agree, but I don't know how to do it either. Maybe it's somehow possible to convert all the patches into git commits, which would definitely allow for pretty easy bisecting. I might look into that later if I can't figure it out by just normal debugging :)

is it worth using Wine Staging for SkyrimSE or FO4?

Not as far as I'm aware, I'm using vanilla wine for both and they work fine for me :)

[qsniyg]

I'm currently doing a git bisect, but I'm more or less certain that the issue lies within this patchset: https://github.com/wine-staging/wine-staging/tree/master/patches/winebuild-Fake_Dlls . Which is slightly ironic, as it likely fixes LOOT (and possibly affects Vortex), but breaks MO2 (USVFS) in the process.

I'll keep bisecting to find the specific commit that breaks it (found it!, this patch is also likely related as well), but I'm not sure if I'll be able to fix it, as I really don't understand what the patchset is doing.

My guess is that the reason this breaks USVFS is because it adds a "wrapper" around the function, so USVFS hooks the wrapper, however wine's ntdll doesn't call the wrapper, but rather the base function itself (which the wrapper also calls).

Filed a bug report here: https://bugs.winehq.org/show_bug.cgi?id=48410

[jarrard]

nice work

[jarrard]

You know for some reason I cannot get fallout4 to execute via MO2. It just doesn't load.

SkyrimSE is fine. I dunno whats going on. FO4 works by itself. Wondering if there is some bug in MO2 that is unspoken of or something.

[qsniyg]

@jarrard It works fine for me... could you check what MO2 prints in the console?

[Al12rs]

You shout test on a new profile with no mods and default INI settigns option enabled when creating it to make sure it's not some wrong ini setting or mod.

[jarrard]

Whole bunch of 002a:fixme:msvcrt: stuff which can be ignored. Here is a pastebin of the whole mess

https://pastebin.com/RDxjw2gv

This is a new install of MO2 and configuration. I've tried several new attempts so far.

[qsniyg]

@jarrard Strange... it's really unfortunate that MO2 hides stdout though, we could probably have a much better sense of what's going on.

That being said, you're using proton, right? Could you try with vanilla wine instead?

[jarrard]

yeah sure I'll try with normal wine, but that requires steam to also be installed doesn't it? a big process to set that up. Maybe that is the issue, FO4 can't detect steam, tho it seems skyrimse can? just a guess.

UPDAT: YEP it can't see steam... sigh, funny how SKyrimSE is fine with this setup... GOD this is infuriating, hate broken drm.

UPDATE2: Hehe, I just used goldberg, problem fixed. Seriously first time I've encountered that steamplay/proton bug.

The whole idea of using proton is to bypass the need to running a glitchy windows version of steam in the background doing glitchy things each time you play.

[jarrard]

Used proton 5.0rc4 tkg which apparently doesn't have staging, no luck it seems :(

plugin directory = D:\SteamLibrary\steamapps\common\Fallout 4\Data\F4SE\Plugins\
checking plugin D:\SteamLibrary\steamapps\common\Fallout 4\Data\F4SE\Plugins\\mcm.dll
couldn't load plugin D:\SteamLibrary\steamapps\common\Fallout 4\Data\F4SE\Plugins\\mcm.dll (Error 126)
checking plugin D:\SteamLibrary\steamapps\common\Fallout 4\Data\F4SE\Plugins\\PrivateProfileRedirector.dll
couldn't load plugin D:\SteamLibrary\steamapps\common\Fallout 4\Data\F4SE\Plugins\\PrivateProfileRedirector.dll (Error 126)
checking plugin D:\SteamLibrary\steamapps\common\Fallout 4\Data\F4SE\Plugins\\UnlimitedSurvivalMode.dll
couldn't load plugin D:\SteamLibrary\steamapps\common\Fallout 4\Data\F4SE\Plugins\\UnlimitedSurvivalMode.dll (Error 126)
config path = D:\SteamLibrary\steamapps\common\Fallout 4\Data\F4SE\f4se.ini
init complete
RegisterPapyrusFunctions_Hook

Oh wait, nevermind it seems it does according to the cfg files. Blasts.

[qsniyg]

@jarrard I believe any version of proton has the staging patches.

On a sidenote, Paul Gofman wrote a patch that might fix it, but I haven't yet gotten around to testing it.

[jarrard]

Ok np, I'm currently compiling my own version of proton tkg without staging which will likely fail in about 6hrs time once it reaches 99% :)

Also I believe valves default proton does not have staging patches because if you look at their github it only lists wine as a source. (however their using outdated wine4.11 which is not helpful)

If this compile works, I'll do another one with staging and that patch applied after them all. Compile time is very long and I better get to bed soon so won't get to it until tomorrow night.

[qsniyg]

@jarrard Ah you're right, proton doesn't have the problematic patch, though (wine|proton)-tkg, as you say, uses wine-staging by default. Without wine-staging though it should (hopefully) work :)

[jarrard]

Compiled a non-staging proton-tkg 5.0rc4 build today and tested it out and the plugins loaded correctly.

plugin directory = D:\SteamLibrary\steamapps\common\Fallout 4\Data\F4SE\Plugins\
checking plugin D:\SteamLibrary\steamapps\common\Fallout 4\Data\F4SE\Plugins\\mcm.dll
registering plugin listener for F4SE at 1 of 2
plugin D:\SteamLibrary\steamapps\common\Fallout 4\Data\F4SE\Plugins\\mcm.dll (00000001 F4MCM 00000008) loaded correctly
checking plugin D:\SteamLibrary\steamapps\common\Fallout 4\Data\F4SE\Plugins\\PrivateProfileRedirector.dll
plugin D:\SteamLibrary\steamapps\common\Fallout 4\Data\F4SE\Plugins\\PrivateProfileRedirector.dll (00000001 PrivateProfileRedirector 00000029) loaded correctly
checking plugin D:\SteamLibrary\steamapps\common\Fallout 4\Data\F4SE\Plugins\\UnlimitedSurvivalMode.dll
plugin D:\SteamLibrary\steamapps\common\Fallout 4\Data\F4SE\Plugins\\UnlimitedSurvivalMode.dll (00000001 UnlimitedSurvivalMode 01040000) loaded correctly
config path = D:\SteamLibrary\steamapps\common\Fallout 4\Data\F4SE\f4se.ini

Had a strange issue where fullscreen was switching to 30hz for some reason, bizarre issue.

[jarrard]

trying to build a proton tkg staging build with that patch now. Not sure if I set it up right, will see

UPDATE: That patch appears to work with tkg staging so far. Maybe someone else can apply it also and confirm it works. I'll test it with non-patched tkg at some point.

[jarrard]

I noticed that the python plugin fails to launch if you run MO2 from Firefox or a File Manager, you can get around this error by just disabling python. Not sure what consequences that will have.

Python plugin appears to load fine via lutris or steam, I don't understand why this is but if you attempt to run mo2 with python via a filemanager script or firefox nxm script it will crash!

UPDATE: I did notice that xEDIT is unable to drag&drop field data (not entire columns, that works). No sure if that is related to MO2 or not. It appears setting windows version to winxp resolves the xEdit drag and drop issue. Might be a wine bug that needs fixing sometime.

[ecbfry]

Have been following this discussion - great work you're doing. I can confirm that the patch works on top of Glorious Eggroll's latest custom proton (proton-ge-5), which was surprisingly easy to build following GE's instructions. I am now able to run MO v2.2.1 from steam (native linux) and launch SkyrimSE from MO, with USVFS working including SKSE mods (tested with Stay at the System Page).

[jarrard]

MO2 2.2.2 is out now. I never had much luck building GE versions for some reason, the build environment kept spitting out errors (vagrant). TKG is fine tho.

Also I'd like to point out you can use https://gitlab.com/Mr_Goldberg/goldberg_emulator to bypass steam so you can use wine builds without needing the steam app running via wine also. In saying that there is apparently git hub projects that will pass wine games to linux steam also but I haven't tried those. (handy for proper online gaming support)

[jarrard]

Some things of concern that might need to be looked into with MO2 at some point.

1st) Dragging mods and dropping them leaves the contextual popup up until mouse is right-clicked somewhere. (happens almost all over the place for MO2 with all wine versions). Related console output (may not be related)

0029:fixme:shell:IDropTargetHelper_fnDragOver (0xd745220)->(0x2286b0 0x00000002)
0029:fixme:shell:IDropTargetHelper_fnDrop (0xd745220)->(0xe53e830 0x2286a8 0x00000002)
0029:fixme:shell:IDropTargetHelper_fnDragEnter (0xd745220)->(0x30090 0xe5e5ec0 0x2286a8 0x00000002)

2nd) On MO2 startup and usage there is allot of "GetFileVersionInfoSizeW()...... Resource data not found. (0x714)" error readouts for all the dll files, seems to struggle reading file version info which might cause issues?

3rd) Write access messages to drives, do other people get these errors? they seem to be false alarms. wine: Read access denied for device L"\\??\\D:\\", FS volume label and serial are not available.

4th) There is a collator error that pops up when trying to open a mod url, it CAN cause MO2 to freeze for a minute then resumes afterwards with these error outputs. Unsupported flags (9) used in QCollator

5th) The USVFS system fails after a couple uses then MO2 needs to be restarted.

Some of these error messages I've managed to get rid of by installing random winetricks packages but sometimes that can make things worse so isn't recommended until we can figure out for 100% certainty they are helping resolve issues.

mo2_wine_console_output.txt

Other errors like the below are probably of more concern.

0029:err:combase:RoGetActivationFactory Failed to find library for L"Windows.UI.ViewManagement.UISettings"

[isanae]

2nd) On MO2 startup and usage there is allot of "GetFileVersionInfoSizeW()...... Resource data not found. (0x714)" error readouts for all the dll files, seems to struggle reading file version info which might cause issues?

It's harmless. I added a bunch of logging in 2.2.1 and 2.2.2 to get the list of all loaded DLLs in the process, along with their size, timestamp and version number. Files outside of system folders also log their md5.

This error happens when MO can't read the version info structure in the module. I'm already handling 0x715 (ERROR_RESOURCE_TYPE_NOT_FOUND), but I wasn't aware of 0x714 (ERROR_RESOURCE_DATA_NOT_FOUND). I'll make sure to silence this warning in the future.

3rd) Write access messages to drives, do other people get these errors? they seem to be false alarms. wine: Read access denied for device L"\\??\\D:\\", FS volume label and serial are not available.

When exactly do you get these messages?

4th) There is a collator error that pops up when trying to open a mod url, it CAN cause MO2 to freeze for a minute then resumes afterwards with these error outputs. Unsupported flags (9) used in QCollator

Did you really mean to say "open a mod url"? Are you talking about the "Visit on Nexus" context menu item? The only direct use of QCollator seems to be in the mod info dialog for natural sorting, but 9 is never passed as a flag. It's used all over the place internally by Qt, so who knows. I also doubt the QCollator itself would make MO hang, it's probably something that happens right after it's used.

[jarrard]

When exactly do you get these messages?

Seems to appear at start, I think their harmless and are only complaining about the mounted drives have no defined serial or volume label..

Did you really mean to say "open a mod url"? Are you talking about the "Visit on Nexus" context menu

Yes it seems this gets glitchy now and then. I frequently need to restart MO2 to bypass some of these odd issues. If you load up FO4Edit/Game, or install multiple files it seems to randomly cause MO2 to halt or freeze/crash eventually.

[isanae]

Seems to appear at start, I think their harmless and are only complaining about the mounted drives have no defined serial or volume label..

Another thing I log on startup is the free space on all drives involved in the various paths used by MO, that might be it.

If you load up FO4Edit/Game, or install multiple files it seems to randomly cause MO2 to halt or freeze/crash eventually.

Does it generate core dumps? If so, you might want to upload it here or on discord.

[jarrard]

Yes tho I can't be certain this is a related dmp file, it is for today but sometimes I must force kill the MO2 process which could interfere with output.

ModOrganizer.exe-40.dmp.zip

Next time I get issues I'll try and capture whats happening. If it allows me.

[jarrard]

Got some log data for when MO2 glitches out randomly sometimes and fails to load xedit or fallout4.

 Error 87 ERROR_INVALID_PARAMETER: Invalid parameter. (0x57)
 . binary: 'D:\SteamLibrary\steamapps\common\Fallout 4\FO4Edit.exe'
 . owner: GetEffectiveRightsFromAclW(), Invalid function. (0x1)
 . rights: GetEffectiveRightsFromAclW(), Invalid function. (0x1)
 . arguments: ''
 . cwd: 'D:\SteamLibrary\steamapps\common\Fallout 4'
  . stdout: no, stderr: no, hooked: yes
 . MO elevated: yes
. usvfs x86:ok x64:ok proxy_x86:ok proxy_x64:ok

Also does MO2 de-case file and folder names when it creates the virtual FS? I notice lots of folders and files have variations of case sensitive spelling. I think its handling it correctly, just haven't seen a confirmation about this.

[isanae]

Unfortunately, ERROR_INVALID_PARAMETER is set by usvfs in what's basically a catch-all handler in CreateProcessHooked(). You might have a more detailed error in the usvfs log on a line that says failed to inject.

As for casing, there's some logging that uses lowercase, like the loaded modules. There are no case conversions in usvfs as far as I'm aware.

[jarrard]

I think this is the correct error output for the usvfs log .

21:12:42.265 [D] proxy timeout
21:12:42.265 [E] failed to inject: C:\git\modorganizer-release\build\usvfs\src\usvfs_helper\inject.cpp(164): Throw in function void __cdecl usvfs::injectProcess(const class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > &,const struct usvfsParameters &,void *,void *)
Dynamic exception type: struct boost::wrapexcept<struct timeout_error>
[struct tag_message * __ptr64] = proxy didn't complete in time
21:12:42.265 [E] proxy didn't complete in time

As for case issue, well provided that MO2 sees Cow2.xxx and cow2.XXX as the same thing and handles them correctly.

UPDATE: ......xfce bad font for wine.....

UPDATE2: The font issue seems to be mostly related to XFCE because switching to Plasma5 and it looks just fine. I have since removed XFCE from my system; it was a nice experimental test drive but plasma just wins in the end.
(no idea howto fix XFCE ugly font with wine, maybe it was missing anti-aliased font settings)

[jarrard]

I thought I should ask this here, and its a minor issue.

The option to Lock MO2 while exe is running no longer works, it did work in older versions (2.1? ) But not now. I installed dotnet4.6 thinking that was the issue maybe but no luck. Perhaps this feature also doesn't work anymore under windows?

It's a minor thing.

Notes on current MO2 Linux status:

At this point in time MO2 mostly works with wine5/staging5, people will experience odd problems where MO2 will fail to load the VFS+EXE (tools/game) randomly and need to restart MO2.

These issues are likely some odd permissions failure happening with WINE and could even be due to me using NTFS for these games/files.

I intend to upgrade to straight EXT4 partition in the future (waiting on new NVMe) and will be able to test under native conditions then.

NOTE: Some window managers will cause semi-messed up font (ie. XFCE)

[MagicRB]

@jarrard This is slightly of topic, but I've had success with btrfs, it works nicely on Linux and also on windows if you need to dual boot. The windows driver is called WinBTRFS

[jarrard]

@jarrard This is slightly of topic, but I've had success with btrfs, it works nicely on Linux and also on windows if you need to dual boot. The windows driver is called WinBTRFS

Yes I know about WinBTRFS, the only reason I don't use BTRFS is because its performance 'WAS' allot worse then EXT4 for stuff like running games on. I have not see updated performance comparisons however (also I use NVMe which some FS will gimp).

For reference: Phoronix BTRFS Benchmarks / Linux 5.0 ... One could argue XFS is better but I don't think it has support under Windows (correct me if I'm wrong).

Under windows there is a company called Paragon Software who make a EXT4 driver tool but its not free. Just be sure to backup your USER folder before using any windows based Linux file system mounting tool because I've had SEVERAL situations now where permissions or something get messed up and wasn't able to login (stalls on Linux login) afterwards.

[MagicRB]

@jarrard This is slightly of topic, but I've had success with btrfs, it works nicely on Linux and also on windows if you need to dual boot. The windows driver is called WinBTRFS

Yes I know about WinBTRFS, the only reason I don't use BTRFS is because its performance 'WAS' allot worse then EXT4 for stuff like running games on. I have not see updated performance comparisons however (also I use NVMe which some FS will gimp).

For reference: Phoronix BTRFS Benchmarks / Linux 5.0 ... One could argue XFS is better but I don't think it has support under Windows (correct me if I'm wrong).

Under windows there is a company called Paragon Software who make a EXT4 driver tool but its not free. Just be sure to backup your USER folder before using any windows based Linux file system mounting tool because I've had SEVERAL situations now where permissions or something get messed up and wasn't able to login (stalls on Linux login) afterwards.

Permissions are easy to fix and i'm not going to lie to and tell you that there is no performance impact, however I run almost everything on btrfs and the impact is in my opinion minimal.

[jarrard]

Permissions are easy to fix

Yes except fixing permissions did not fix the issue, something was touched in a nasty way. Mind you this only happened with Paragon software which I filed a bug report about.

Since I plan to run via NVMe that runs at 3500MB/s, being gimped down to 500-700MB/s is significant. I will conduct some performance measure tests once my NVMe arrives to determine if BTRFS is ok or not.

PS. It should be noted that FO4/Bethesda games are quite aggressive texture reading, meaning they touch the disk allot, if I/O is 1/4th that of EXT4 then its quite a bad performance hit!

[AnyOldName3]

Is the best EXT4 implementation for Windows really proprietary and paid? It's an open standard, with open implementations, so there shouldn't be anything giving a proprietary implementation an advantage. I know I've interacted with EXT4 volumes on Windows before without any problems or money leaving my account.

[MagicRB]

@AnyOldName3 yes, the only "safe", ext4 implementation on windows is the one by paragaon. From what I understand ext4 isn't the problem, rather the nt kernel APIs are