Vault locked but still visible in explorer

I bought the android app at 2018, at the very first beginning.
i would say it’s still at the beginning now.

ctmt say the vault is locked

indeed it’s mounted.
image

when I click unlock, itself also say already unlocked:

as text at bottom:

problem:
I want to go on street NOW, I can’t “lock” it back!
WxF should I do?

platform 64bit win10 pro, v1.6.15, dokany.
vault on google drive

Error Code 9JKD:5BPT:5BPT
java.lang.IllegalStateException: Already unlocked.
	at org.cryptomator.desktop@1.6.15/org.cryptomator.common.vaults.Vault.unlock(Vault.java:148)
	at org.cryptomator.desktop@1.6.15/org.cryptomator.ui.keyloading.KeyLoadingStrategy.use(KeyLoadingStrategy.java:79)
	at org.cryptomator.desktop@1.6.15/org.cryptomator.ui.unlock.UnlockWorkflow.attemptUnlock(UnlockWorkflow.java:72)
	at org.cryptomator.desktop@1.6.15/org.cryptomator.ui.unlock.UnlockWorkflow.call(UnlockWorkflow.java:62)
	at org.cryptomator.desktop@1.6.15/org.cryptomator.ui.unlock.UnlockWorkflow.call(UnlockWorkflow.java:35)
	at javafx.graphics@18.0.2/javafx.concurrent.Task$TaskCallable.call(Task.java:1426)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)

Have you tried to put files in your vault when it’s unlocked but still the drive is available?
It’s a typical WebDAV issue that it does not „clear“ the explorer even when the drive is not available anymore.

I know you wrote that you already use dokany, but please double check if it is configured in your vault settings.

1st of all I am not a naive user, I know what stable software is, and what is not acceptable.

I 1st chose dokany in the settings,
then it appear error as at the bottom.

it sucked.

Then i chose webdav, which appear a port number.
i have to said i never chose this option as i never see that number before.

A. it can mount, and can unmount cleanly.

B. then I doubt if any of these (webdav, dokany, fuse) is vault specific? when I create the vault.
so I chose fuse and mount. it can mount, and unmount cleanly.

Fun, then i try dokany.

C. now dokany can mount, and unmount cleanly.

For me what I look like is this software is unstable, asking users to help troubleshoot problems which i guess should be in the beta version tested by someone else.

PART 2:
while I am typing and wanna repeat the above, this error happened:
It should be at drive Q. i cant lock it yet it is unmounted.
And I am just trying to mount/unmount and NOT copying any files!
CTMT is just that level, I wish you guys all the best.

I guess you guys understand what is unacceptable.

image

image

It’s like the Chinese visit Russia, wanna buy fighter planes, and the Mig-29 fall to the ground at the demo show. So the Chinese chose Su-27 series instead.

bottom:

Error Code S3RS:OSDR:20VC
org.cryptomator.common.vaults.Volume$VolumeException: Unable to mount Filesystem
	at org.cryptomator.desktop@1.6.15/org.cryptomator.common.vaults.DokanyVolume.mount(DokanyVolume.java:48)
	at org.cryptomator.desktop@1.6.15/org.cryptomator.common.vaults.Vault.unlock(Vault.java:155)
	at org.cryptomator.desktop@1.6.15/org.cryptomator.ui.keyloading.KeyLoadingStrategy.use(KeyLoadingStrategy.java:79)
	at org.cryptomator.desktop@1.6.15/org.cryptomator.ui.unlock.UnlockWorkflow.attemptUnlock(UnlockWorkflow.java:72)
	at org.cryptomator.desktop@1.6.15/org.cryptomator.ui.unlock.UnlockWorkflow.call(UnlockWorkflow.java:62)
	at org.cryptomator.desktop@1.6.15/org.cryptomator.ui.unlock.UnlockWorkflow.call(UnlockWorkflow.java:35)
	at javafx.graphics@18.0.2/javafx.concurrent.Task$TaskCallable.call(Task.java:1426)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)
Caused by: org.cryptomator.frontend.dokany.DokanyMountFailedException: Error while mounting.
	at org.cryptomator.frontend.dokany@1.3.3/org.cryptomator.frontend.dokany.MountFactory.mount(MountFactory.java:130)
	at org.cryptomator.frontend.dokany@1.3.3/org.cryptomator.frontend.dokany.MountFactory.mount(MountFactory.java:116)
	at org.cryptomator.desktop@1.6.15/org.cryptomator.common.vaults.DokanyVolume.mount(DokanyVolume.java:43)
	... 11 more
Caused by: com.dokany.java.DokanyException: DokanMain returned error code-4: Dokan mount failed - Driver answer that something is wrong.
	at org.cryptomator.frontend.dokany@1.3.3/com.dokany.java.DokanyMount.lambda$mount$2(DokanyMount.java:97)
	... 1 more

image

appeared now.

i really don’t know how to trust this.

i am done.

ps:
back to ground zero:

vault opened and I can’t umount it, can’t lock back.
and this makes me worry about data lost.

I use it personally, i can tolerate SB.

if i am in commercial, will i risk my career and suggest ctmt to my boss?

We’re gradually moving away from Dokany (and WebDAV for much longer) and towards WinFsp (on Windows). You may have seen the notice in the downloads page that WinFsp is included in the EXE installer. Have you already tried the volume type “FUSE”?

In our opinion, this should be much more stable, hence we’re making this gradual switch. I understand that it’s frustrating to encounter weird issues with the virtual drive. They’re surprisingly very complex technologies since they’re deeply integrated into the operating system. And you can’t believe the broad range of system configurations and user requirements we’ve encountered.

We’re actually working on a major under-the-hood improvement regarding the mounting implementation, which is scheduled for 1.7.0. In the meantime, your best bet is to stick to FUSE, which should be the default in a fresh installation.

Locked devices or files/folders are typical bugs of the underlying OS. It’s like unmounting a USB stick, and OS says the device is in use, but all apps are closed. The software has to flush all buffers explicitly and ovoid lazy writes or shared reads to get rid of this.