search

cryptomator / cryptomator

Cryptomator for Windows, macOS, and Linux: Secure client-side encryption for your cloud storage, ensuring privacy and control over your data.
https://cryptomator.org
GNU General Public License v3.0
11.73k stars 1.02k forks source link

WinFsp Mount Point directory gone after Vault locked #3487

Open tonyrulez opened 3 months ago

tonyrulez commented 3 months ago

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

  1. Create empty folder for mounting kép
  2. Set Vault to use WinFsp (Local Drive) Volume Type
  3. Set Mount Point to folder created in step 1
  4. Unlock Vault
  5. Vault gets mounted under Folder kép
  6. Lock Vault
  7. Unlock Vault again
  8. Error message popup, directorty created for Mount Point is gone kép

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

infeo commented 3 months ago

@tonyrulez Can you upload a log file following these instructions?

  1. Start Cryptomator
  2. Create a new vault stored locally on your harddrive
  3. Set up a custom mountpoint next where the problem with the current mountpoint occurs
  4. Enable Debug mode in Cryptomator
  5. Unlock the vault
  6. Lock the vault
  7. Quit Cryptomator

and upload the log file (named cryptomator0.log)

tonyrulez commented 3 months ago

cryptomator0.log

Log above. Did 2 cycles of unlocking, because the folder/link got deleted just before unlocking for the 2nd time

infeo commented 3 months ago

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.

tonyrulez commented 3 months ago

@infeo yes, when unlocked the hidden sibling is present.

kép

tonyrulez commented 3 months ago

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

infeo commented 3 months ago

@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

tonyrulez commented 3 months ago

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?

tonyrulez commented 3 months ago

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.

infeo commented 3 months ago

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!