mount: On Windows mounting two directorys in a row fails for the second one

[infeo]

Basic Info

OS: Windows 10
fuse-nio-adapter: commit 426439b

Description

Mounting a directory after another mount operation was executed fails. (No matter if the latter directory is still mounted or already unmounted.)
On linux with the native fuse-layer it works.
Also noteworthy is the fact, that with two independent processes it works but with two threads it fails.

Attachments

Enter path to the directory you want to mirror:
Y:\test
Enter drive letter to use:
J
The service java has been started.
Mounted successfully. Enter anything to stop the server...
quit
Unmounted successfully. Exiting...
The service java has been stopped.
Mount again?(y/n)
y
Enter path to the directory you want to mirror:
Y:\tresor
Enter drive letter to use:
K
The service java has failed to run (Status=c000010e).
ru.serce.jnrfuse.FuseException: Unable to mount FS
	at ru.serce.jnrfuse.AbstractFuseFS.mount(AbstractFuseFS.java:286)
	at org.cryptomator.frontend.fuse.WindowsMirroringTest.main(WindowsMirroringTest.java:33)
Caused by: ru.serce.jnrfuse.FuseException: Unable to mount FS, return code = 1
	at ru.serce.jnrfuse.AbstractFuseFS.mount(AbstractFuseFS.java:282)
	... 1 more

[billziss-gh]

This is a limitation of WinFsp-FUSE (i.e. the FUSE layer of WinFsp): you can only have one file system per process. The reason is explained below.

There is no such limitation in the core WinFsp layer. You can have as many file systems as you want in a process either simultaneously or one after another. However file systems in Windows need to often be run as services and for this reason the core WinFsp layer also provides an API to facilitate this.

The WinFsp-FUSE layer uses both the file system and service API's. 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 (this is true of the WinFsp Service API, although I do not remember if this is an inherent limitation of the Windows Service API).

Having FUSE file systems being able to act as Windows services is valuable. The downside is that you can only have one FUSE file system per process. Unfortunately this is not a limitation that I can fix as FUSE file systems would lose the "free" ability to act as Windows services.

[overheadhunter]

Unfortunately this is not a limitation that I can fix as FUSE file systems would lose the "free" ability to act as Windows services.

Might be a silly question, but isn't it possible to leave it up to the user to decide if he either wants the service thing or multiple mounts per process? In our case we'd decide for the latter.

[billziss-gh]

@overheadhunter not a silly question :) Unfortunately this is not how it was done! Changing it to support both scenarios is non-trivial at this point.

May I ask why you need to have more than one fs per process? Is it for testing purposes or do you actually need this in your final product?

[infeo]

Currently our software uses one process and is able to mount and unmount different directorys repeatedly (over webdav). Due some drawbacks of webdav we want to offer an alternative (FUSE), but changing to a multiple process architecture would mean a lot of refactoring. Therefore it would be cool when using FUSE/WinFsp this just needs one process at all 😄

[billziss-gh]

@infeo thank you for the explanation. I will have a look to see whether what you want is possible. I am currently in the midst of a difficult change in the WinFsp FSD (File System Driver) so this might take a while.

BTW, the relevant code is in service.c.

[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.

3. 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?

[overheadhunter]

@billziss-gh as some time has passed, can you give us an update on this topic? We're about to release the first beta of Cryptomator with FUSE support for Mac and Linux and might need to think about an alternative for Windows otherwise. I really like how simple WinFsp works and would like to stick with it!

[billziss-gh]

@overheadhunter I understand. I have not had the chance to look into this as I have been busy with other projects.

[overheadhunter]

Closing this, as we no longer aim to support Windows. We're moving to dokany-nio-adapter.