WebGL for Chrome(book) emscripten FS missing or fails initializing?

Hi
I am upgrading an old project in production/maintenance mode from Unity 5.4 to a more modern Unity version (2017.2).

The project use emscripten FS for file operations. This worked fine in 5.4 when we accessed window.FS when I run the project built using 2017 window.FS is not defined or somehow not properly initialized and calls to it fail silently.

I have checked the Unity 2017 manual and change logs but have not been able to find anything regarding this.

According to https://kripken.github.io/emscripte...system-API.html#including-file-system-support I should be able to force filesystem inclusion in builds by using -s FORCE_FILESYSTEM=1 - I tried setting this using

Code (CSharp):

1. PlayerSettings.SetPropertyString("emscriptenArgs", " -s FORCE_FILESYSTEM=1", BuildTargetGroup.WebGL);

Some times I get a FS undefined error - and other times I get "warning: 2 FS.syncfs operations in flight at once, probably just doing extra work" - which is thrown by emscripten - so FS is available some times, but none of the calls I make to its functions completes successfully.

So I am doing something wrong. How am I supposed to initialize/include FS in webgl builds made using Unity 2017?
I have also tried building with and without stripping but FS is still undefined or fails initializing silently at runtime.

 

The only error I get (if I wrap my invocation of FS.syncfs in try catch) is an error that says either FS is undefined or the "warning: 2 FS.syncfs operations in flight at once, probably just doing extra work" message from the emscripten FS source.
So the sources are available - it must the the initialization that fails for some reason. Our application was historically running with a webgl memory setting of 384MB that worked well for us on the 5.4 builds - but that might need to be adjusted on the new Unity version.

I can see that if I reduce the 384MB to 256 - I consistently get the FS is undefined error instead of it sometimes being defined and other times not. So I will do some more tests of the memory setting.

I have not put the code into a jslib (yet) - would that be more efficient?

 

Ok, I did read it but was hoping to do the transition incrementally instead of in one big go as we have a very large application that uses quite a few javascript libraries and a lot of Application.ExternalCall. But I will do the transition now and see if that doesn't change the FS behaviour.
Thanks

 

I did a small experiment and found a hacky workaround that indicates it is a scoping issue in my application.

Since the rewrite to jslib would be quite time consuming, I started looking for alternatives to be able to test the application continuously while we refactor - babysteps .

Stepping through the Unity application webgl initialization I realized that unityInstance.Module eventually contains keys that map to some of the FS functions (keys prefixed with FS_ in webgl_application.asm.framework.unityweb) and after onRuntimeInitialized is fired, I can invoke them from my own code without issues.

So as a small experiment I patched the generated
webgl_application.asm.framework.unityweb file and inserted a Module["FS"] = FS next to one of the other Module["FS_...."] mappings.

Then in the onRuntimeInitialized callback I set window.FS = unityInstance.Module.FS (for no other reason than that is what our old application expects) and now my old application is running perfectly fine without having refactored to jslib usage yet.

I will still do the rewrite to jslib, this was just a quick experiment.