Delay before start of copying

When I copy some files to my vault, before the actual copy process begins there is a significant time when seemingly nothing happens. In the task manager I can see a lot of writing onto the HDD, which seems to me like Cryptomator is reserving this space? But why is this happening? Is this really necessary as this basically doubles the time required to copy the files? And the bigger the file size the longer the time before the actual copying begins.

Another problem with that is, that you cannot easily abort this process. If I try to abort the copying process in this first phase, it doesn’t abort. The only option is to kill Cryptomator in Task Manager. After the copying begins you can abort it with no problem, but this may take hours for larger files to get to this second phase.

It is actually extremely annonying issue and I would be really grateful if you could fix that.

I am using the latest Cryptomator 1.6.15 with FUSE. I tested this problem with OneDrive, Google Drive and local drive vault.

Hi. This is not normal. The copy process should start immediately, and there should be no delay.
I tried to reproduce that, but cant. In fact, there’s no significant speed difference if I copy a file in a vault, or anywhere where the vault is located.

Anything suspicious in the log file?
Does this also happen if you use Dokany instead of WinFSP (=FUSE)

I did some testing and here are the results.

This problem does not occur with Dokany.

I tested copying with the same 4.9 GB test file.
It took Dokany 72 s and the copying process started immediately.

It took FUSE 226 s in total, which of them 84 s was the first phase in which the copying seemingly does not progress (in the copy dialog of a file manager).

I did the testing even with WebDAV, but the test file was 517 MB.

Here is the log of copying a tiny txt test file using FUSE.

Cryptomator debug.log (89.2 KB)