Open tonyrulez opened 3 months ago
@tonyrulez Can you upload a log file following these instructions?
and upload the log file (named cryptomator0.log)
Log above. Did 2 cycles of unlocking, because the folder/link got deleted just before unlocking for the 2nd time
I honestly cannot think of why this happens, the log file does not contain an error line in the expected region. Line 109 that the mountpoint was not released/reestablished.
INFO o.cryptomator.common.mount.Mounter - Mountpoint "P:\Backup\winfsp" is still a junction. Deleting it.
But the lines before do not contain an indicator that the cleanup failed.
WinFsp does not support mounting to existing targets, only to not existing ones. In order to fit into Cryptomators UI, we have the following workaround:
During locking:
@tonyrulez If you unlock a vault with a directory mountpoint, does it parent contain a hidden sibling? E.g. if you mount to C:\foo\bar
, after unlock the hidden directory C:\foo\.~$bar.tmp
should exist.
@infeo yes, when unlocked the hidden sibling is present.
Maybe this is helpful, here is a ProcMon save of all File operations containing the mount folder name during failed unlocking of the vault: https://github.com/tonyrulez/file_dump/raw/main/Logfile.PML
@tonyrulez According to your logs is your mountpoint not only a directory, but also a reparse point:
Date: 10/07/2024 10:45:39.7873436 Thread: 6420 Class: File System Operation: CreateFile Result: REPARSE Path: P:\Backup\winfsp Duration: 0.0000086
Ok, I don't know what a reparse point is, but the mountpoint folder is located on a DrivePool that consists of 4 drives. So far I had no issues with file operation on this pool. Maybe WinFsp doesn't like it?
Bypassed the issue by moving the mount point directory outside of the pool. Cryptomator no longer has a problem unlocking the vault for the second time as it can recreate the directory without any issue.
So this seems like to be a problem with DrivePool and/or WinFsp.
So this seems like to be a problem with DrivePool and/or WinFsp.
It's actually an issue of our implementation. Need to think more of it, but i think we don't handle the case correctly, if some component (but not the last one) of the mountpath is a symlink/reparse point.
But glad there is a workaround!
Please agree to the following
Summary
After Cryptomator Vault is locked, Mount Point directory gets deleted
What software is involved?
Volume Type
WinFsp (Local Drive)
Steps to Reproduce
In order to mount vault again, mount point directory needs to be recreated
Expected Behavior
Do not delete mounting folder after vault is locked. This was the behaviour with Dokany, before it became unsupported. Or, if folder needs to get deleted, recreate it automatically before mounting.
Actual Behavior
Unable to mount Vault to folder, because it gets deleted after each Lock
Reproducibility
Always
Relevant Log Output
No response
Anything else?
No response