FUSE: Allow multiple file systems in the same process

[stanimirivanovde]

This is a serious issue for me. I have two separate use cases that need this:

1. Can't create integration style JUnit tests. Each test mounts the file system and executes an operation (read/write/create etc). After the first test runs and the file system is unmounted all consecutive unit tests fail. Based on your explanation, once you call umount() on a mounted file system you can't remount a new file system in the same process. This means the only way to integration test a file system is to use the same mounted instance and carefully control all operations to it. Not really ideal but I guess can be a major inconvenience work around. I want each of my unit tests to create a new mount and perform an operation on the file system. Another work around would be to have only one test per physical JUnit source file. This way JUnit will execute each test in a separate process, but that is not good because it will cause many files to be created with only one test in them.

2. This is a show stopper for any encrypted style file system ala Truecrypt/Veracrypt that allows the user to select multiple encrypted containers and mount them through the same process. This means that a new instance of the entire application should be executed in order to mount a separate encrypted volume. Not to mention that this is very inefficient, but it will require more refactoring then actually I am ready to perform right now.

This works well on Linux and Mac OS X so the Windows limitation was a big surprise.

I am using WinFSP with jnr-fuse. And on my Mac OS X jnr-fuse works pretty well. But the Windows port has been spotty and my unit tests can't run at all on Windows because of the above reasons. Do you think there is anything that can be done to have a workaround?

[billziss-gh]

This is indeed a limitation of the WinFsp-FUSE layer currently. I quote the reasons that this limitation exists from the FAQ:

WinFsp-FUSE does not have the ability to support multiple file systems from within the same process. Why?

The core WinFsp layer supports multiple file systems in the same process either simultaneously or one after another. However this is not the case with WinFsp-FUSE (i.e. the FUSE layer of WinFsp).

File systems in Windows often need to be run as services. For this reason the WinFsp-FUSE layer provides both file system and Windows service API functionality. This way a WinFsp-FUSE file system can easily become a Windows service. There is a problem: once a Windows process starts acting as a service and then stops being a service, it cannot become a service again.

Having FUSE file systems being able to act as Windows services is valuable. Therefore this is not a limitation that can easily be fixed as FUSE file systems would lose the "free" ability to act as Windows services.

It may be possible to remove this limitation for a process that does not wish to become a service. I will have a look and see if it is possible.

[billziss-gh]

Can't create integration style JUnit tests. Each test mounts the file system and executes an operation (read/write/create etc). After the first test runs and the file system is unmounted all consecutive unit tests fail.

BTW, is it not possible to mount the file system once during the start of the tests? I seem to recall that JUnit had this capability.

[stanimirivanovde]

I worked around the issue of JUnit tests by writing a bash script to run each test separately in a new JVM. I couldn't get Gradle to work correctly even if --no-daemon option was passed to it and a separate instance were executed for each test. I assume this is due to the fact that somehow Gradle is sharing the same JVM for each test? But I don't know. I had to do direct Java class instantiation which is ugly but it works well for my testing purposes.

[WalkerKnapp]

Are there any updates on this issue? This is a pretty crippling flaw for my usecase, but I would love to take advantage of the speed boost of moving to winfsp.

[billziss-gh]

Unfortunately I do not have an update on this yet. I intend to look at it, but I am currently occupied with other projects and do not have time for it.

If anyone wants to tackle this, the relevant code is in service.c.

[billziss-gh]

I am investigating this issue and considering various solutions.

[billziss-gh]

Commit ae8e4e6 will likely resolve this issue.

Because this is a fundamental change in how FUSE loops are being run, a lot of additional testing needs to be done on this change.

[billziss-gh]

I believe this problem has been resolved. The fix should be included in the upcoming 2018.2 B2 release.