Check for openFileHandles before regular unmount to cancel it

[infeo]

If a file channel is still open when one executes the unmount method ( which in the end calls the linux helper command fusermount), the unmount fails with a CommandFailedException:

fuse-nio-adapter/src/main/java/org/cryptomator/frontend/fuse/mount/AbstractMount.java

Lines 46 to 53 in 4bb19ad

	public void unmount() throws CommandFailedException {
	if (!fuseAdapter.isMounted()) {
	return;
	}
	Process proc = ProcessUtil.startAndWaitFor(getUnmountCommand(), 5, TimeUnit.SECONDS);
	ProcessUtil.assertExitValue(proc, 0);
	fuseAdapter.umount();
	}

Nonetheless, with the call fuseAdapter.unmount() the actual filesystem is marked as not-mounted, make it impossible to recover from the failed regular unmount command:

fuse-nio-adapter/src/main/java/org/cryptomator/frontend/fuse/ReadOnlyAdapter.java

Lines 266 to 273 in 4bb19ad

	public void umount() {
	// this might be called multiple times: explicitly _and_ via a shutdown hook registered during mount() in AbstractFuseFS
	if (mounted.compareAndSet(true, false)) {
	LOG.debug("Marked file system adapter as unmounted.");
	} else {
	LOG.trace("File system adapter already unmounted.");
	}
	}

Additionally, the CommandFailedException for the fusermount only means that the operation did not succeeded, but does not indicate for what reason.

I propose to change the regular unmount to _ only_ execute fusermount and marking the filesystem as unmounted, if no internal file channels are open and otherwise throw a different exception. If the filesystem need to be unmoutned, the unmountForced() method can be used.

Ideas how to implement can be taken from cryptomator/dokany-nio-adapter@9a65c64

[overheadhunter]

With 663ab4d, the mounted flag is no longer set atomically at the begin of execution but after successful unmount only. Note, there is no longer any protection against invoking unmount multiple times.

That said, there is not yet any "open file handle counter".

[infeo]

An easy way to implement the feature is to use the Read/Write-locks. These are applied before nearly every (important) method. hence only if currently no lock is accquired we give the green light to release.

[overheadhunter]

An easy way to implement the feature is to use the Read/Write-locks. These are applied before nearly every (important) method. hence only if currently no lock is accquired we give the green light to release.

True. If it is possible to create an exclusive (i.e. write) lock for the root path, we can be sure, no other operation holds a lock.

Problem is, that currently there is no "root". Locking starts one level below root, since there has never been the need for file operations on root.