MO2 VFS, Windows Filesystem Layers, and Compile issues

[iarna]

Hi, so I recently updated and ran into the program claiming that compile problems were caused by MO2 and I have reason to think you're not entirely correct. (Or it's reporting non-MO2 problems as MO2 problems.)

For many years, I was the primary maintainer of npm (the node package manager) and we ran into exactly the same "file appears to be use" type errors when operating on a bunch of things in parallel. This seems to be a design limitation of the Windows layered filesystem thing -- it does not happen on any other operating systems.

Our solution was a simple one:

Retry failures a few times in the filesystem library. This basically eliminated the problem.

In my case, the error I encountered in Synthesis was resolvable by forcing Synthesis to retry compiling the patcher by telling it to math the version, then go back to the latest version. This, in my experience, fixes the problem every time.

I suspect the MO2 VFS exacerbates the problem by adding further delays to filesystem operations, which results in the access errors we encounter. So MO2 is related to the problem, but the underlying problem is the Windows filesystem layer. Should that be true, it likely is also possible to avoid the issue by creating a Dev Drive and then putting MO2 and Skyrim on there (assuming the VFS works there at all -- Dev Drives eliminate the usual layered filesystem stack, to make things like git not be dog slow on big repos.)

I would strongly suggest adding at least a few retries for file access issues, especially from external processes (like the compiler).

[Noggog]

Heya! Thanks for the thoughts!

Hmm, I have yet to see dotnet build on a straight windows machine ever trigger an "access denied" error. I've compiled an insane amount of code at once and never seen it in other situations. (compiling 2x the entire Mutagen repo brings my CPU to 100% and would weigh down a small elephant). Mo2 devs themselves have mentioned they didn't code their VFS with multithreading in mind. With mo2, even with a small number like two tiny patchers building, i was able to reproduce the access denied issue ~50% of the times attempted. That's a crazy high ratio. With retry 3x, that'd still fail 12% of the time and we'd be back where we're at, telling people to avoid doing it. If it was just once in a blue moon that it happened, I'd agree that a retry might be a good option to consider. But with 50% failure rate (i imagine maybe even higher if more patchers are added).. I think it just needs to be sidestepped entirely

[iarna]

It's definitely much much rarer on plain Windows... there's some sort of race condition at play. The more filesystem layers active, the more likely it will occur. That includes folder level compression, encryption, windows defender, search indexing and also possibly some of Windows built in raid-a-like features, plus of course the VFS layer. I'm may give a try at making a patch just to see how well it works for me.