Empty vault when mounting point is on same file system

Hello,

d:\VAULT1 is my root vault directory. I would like to mount it on d:\DATA1, an empty directory not currently in use by any process (just created). I go to the options and set the mounting point then unlock. There is no error reported but the directory d:\DATA1 is empty.

I get a warning in the log file:

13:50:36.772 [App Background Thread 006] INFO  com.dokany.java.DokanyMount - Dokany API/driver version: 140 / 400
13:50:42.776 [App Background Thread 006] WARN  o.c.frontend.dokany.MountFactory - Mounting timed out.
13:50:42.777 [App Background Thread 006] INFO  o.c.ui.unlock.UnlockWorkflow - Unlock of 'VAULT1' succeeded.

When I choose a mounting point on another drive, like c:\DATA1, it works fine and I see all my files.

Both c: and d: are NTFS on my system. I have Windows 10 and I use Cryptomator v. 1.5.1.1.

Please help.

This indicates it might be also related to the following issue on our tracker:

@Jeffr Cann you also gather an event capture (described here while you mount the vault? (using the failing mount point) You can send me the capture via a PM.

Thank you for your reply. This is what I’ve done:

  1. Created a fresh test vault.
  2. For this vault, activated the “Custom mount options” with the line: " --options CURRENT_SESSION,STD_ERR_OUTPUT --thread-count 5 --timeout 10000 --allocation-unit-size 4096 --sector-size 4096"
  3. Activated “Debug logging”
  4. Created in my home folder a file called “StartCryptomatorWithDokanDebug.cmd” and pasted the following into the file: "“C:\Program Files\Cryptomator\Cryptomator.exe” 2>“C:\Users\admin\dokan.log” 1>“C:\Users\admin\cryptomator.log”
  5. Closed Cryptomator
  6. Lauched StartCryptomatorWithDokanDebug.cmd
  7. Unloked my vault (VAULT1)
  8. On revealing the folder “j:\DATA1” is empty (this is the error).
  9. Locked VAULT1

RESULTS

  1. This what appears in the logfile:
20:36:53.785 [main] INFO  org.cryptomator.launcher.Cryptomator - Starting Cryptomator 1.5.11 on Windows 10 10.0 (amd64)
20:36:53.795 [main] DEBUG org.cryptomator.logging.DebugMode - Debug mode enabled
20:36:53.796 [main] DEBUG org.cryptomator.launcher.IpcFactory - [Client] Reading IPC port from C:\Users\admin\AppData\Roaming\Cryptomator\ipcPort.bin
20:36:53.796 [main] DEBUG org.cryptomator.launcher.IpcFactory - [Client] Connecting to port 50244...
20:36:53.904 [RMI TCP Connection(4)-127.0.0.1] DEBUG o.c.launcher.IpcProtocolImpl - Received launch args: 
20:36:53.905 [main] INFO  org.cryptomator.launcher.Cryptomator - Found running application instance. Shutting down...
20:36:53.906 [ShutdownTasks] DEBUG org.cryptomator.common.ShutdownHook - Running graceful shutdown tasks...
20:36:53.915 [JavaFX Application Thread] WARN  o.cryptomator.ui.fxapp.FxApplication - has visible stages: true
20:36:53.931 [JavaFX Application Thread] DEBUG o.cryptomator.ui.fxapp.FxApplication - Showing MainWindow
20:37:06.958 [JavaFX Application Thread] DEBUG o.cryptomator.ui.fxapp.FxApplication - Showing UnlockWindow for VAULT1
20:37:06.959 [JavaFX Application Thread] DEBUG o.c.common.vaults.VaultStats - stop recording stats
20:37:14.054 [JavaFX Application Thread] TRACE o.c.ui.unlock.UnlockController - UnlockController.unlock()
20:37:14.057 [App Background Thread 006] DEBUG o.cryptomator.cryptofs.ReadonlyFlag - Vault opened for read and write.
20:37:34.878 [JavaFX Application Thread] TRACE o.c.ui.unlock.UnlockController - UnlockController.unlock()
20:37:34.881 [App Background Thread 006] DEBUG o.cryptomator.cryptofs.ReadonlyFlag - Vault opened for read and write.
20:37:35.149 [App Background Thread 006] DEBUG o.c.c.common.MasterkeyBackupHelper - Verified backup file: J:\VAULT1\masterkey.cryptomator.199232D9.bkup
20:37:35.150 [App Background Thread 006] DEBUG o.c.c.m.CustomMountPointChooser - Successfully checked custom mount point: J:\DATA1
20:37:35.151 [App Background Thread 006] DEBUG o.c.frontend.dokany.MountFactory - Mounting on J:\DATA1: ...
20:37:35.151 [App Background Thread 006] INFO  com.dokany.java.DokanyMount - Dokany API/driver version: 140 / 400
20:37:35.648 [JavaFX Application Thread] DEBUG org.cryptomator.common.CommonsModule - Starting App Background Thread 011
20:37:41.153 [App Background Thread 006] WARN  o.c.frontend.dokany.MountFactory - Mounting timed out.
20:37:41.154 [App Background Thread 006] INFO  o.c.ui.unlock.UnlockWorkflow - Unlock of 'VAULT1' succeeded.
20:37:41.183 [JavaFX Application Thread] DEBUG o.c.common.vaults.VaultStats - start recording stats
20:37:45.932 [JavaFX Application Thread] TRACE o.c.u.unlock.UnlockSuccessController - UnlockSuccessController.revealAndClose()
20:38:03.248 [JavaFX Application Thread] DEBUG o.cryptomator.ui.fxapp.FxApplication - Start lock workflow for VAULT1
20:38:03.249 [JavaFX Application Thread] DEBUG o.c.common.vaults.VaultStats - stop recording stats
20:38:03.249 [JavaFX Application Thread] INFO  org.cryptomator.ui.lock.LockWorkflow - Lock of VAULT1 succeeded.
20:38:03.250 [JavaFX Application Thread] DEBUG o.c.common.vaults.VaultStats - stop recording stats
20:38:04.675 [JavaFX Application Thread] DEBUG o.cryptomator.ui.fxapp.FxApplication - Showing Preferences
20:38:07.416 [JavaFX Application Thread] DEBUG org.cryptomator.logging.DebugMode - Debug mode disabled
20:38:08.421 [App Scheduled Executor 02] INFO  o.c.common.settings.SettingsProvider - Settings saved to C:\Users\admin\AppData\Roaming\Cryptomator\settings.json
  1. In Windows event viewer > Windows logs > System, I get 36 information events at 20:27:35 for dokan1 - but I cannot upload the file here because I get the message “Sorry, new users can not upload attachments.” So let me know if you want me to pass it to you by other means.

Thanks.

Hi.

I would greatly appreciate some help on the problem raised.

I would also like to know: has anyone successfully mounted a vault on the same file system, for instance mounting d:\VAULT1 on d:\DATA1? Or do you have the same problem (vault mounted but empty)? So I would know if this is a problem with the product itself or rather with my configuration.

Cheers.

Hi.
I tried to reproduce that but couldn’t.
Vault: d:\somefolder\test
Mountpoint: d:\somefolder\custommountpoint
Works like a charm on my system. Vault is not empty
OS: Windows 10 Pro 20H2
Dokany: 1.4.1.100

Thanks so much :+1:, this gives me a clue at least. I am going to investigate further.

Ok. It turns out that Windows Explorer creates a conflict. I noticed that when I close all my Win. Ex. windows, everything works fine. I can mount the drive and reveal the files in it. But if I am currently having a Win. Ex. window open, it does not work most of the time.

So I tried to refine the diagnostic to determine exactly when it fails, having a Win. Ex. window open.

Remember, my vault is in J:\VAULT1. It turns out that:

  • If I open Windows Explorer and just select the J: drive on the left pane, the mounting works fine.
  • Now if I just expand the content of the J: drive on the left pane, it stops to work. No need to even explore the content of the J:\VAULT1 folder to make the mounting fail.
  • Same result (failure) if I now collapse the J: drive in the left pane and go to another drive letter. At this point one needs to close Windows Explorer to make things work again.

So now I guess I have a workaround, but the question still remains: is that an expected behavior?

Can someone reproduce the same pattern or is it again something to do with my configuration?

Cheers.

Cannot reproduce that either (still on 1.5.11 as you are).

To be more precise to your case, I moved the vault directly to root.
“d:\testvault”.
The mountpoint folder is also in root now
“d:\custommountpoint”

Having the Windows Explorer open, D expanded, D not expanded, even the testvault folder expanded or the custommountpoint expanded. Does not have any negative effect or mount timeout.

The problem you are experiencing might be related to the following issue on our bugtracker:

Maybe some application (explorer, plugin, anything), opens provisionally a handle to the mount directory, which locks the directory and prevents the Dokany driver from transforming the directory into a reparse point.

Thanks Michael, Infeo for the input. Indeed the open handles are the cause.

I have just tested with the sysinternals/handle tool and I could verify that as soon as I expand my J: drive in Windows Explorer, Windows opens not 1 but 2 handles for each subdirectory therein. Then, I only need to close the two handles opened on the mounting point for things to work again.

I don’t know why my Windows Explorer behaves this way on my system. Maybe it’s some other product I’ve installed, but I can’t be sure.

Anyway, this thread can be closed as far as I am concerned.

Cheers.

© 2021 Skymatic GmbH • Privacy PolicyImpressum