Hello everyone, we want to encrypt video data from studies with cryptomator, the files are often several GB in size. I have now read about the 4GB WebDAV issue, but I am using the version 1.5.4 and the settings say it uses Dokany and not WebDAV for which I thought file size is not an issue. However, after unlocking the vault synchronised from the cloud (we did that on several Windows 10 PCs), the explorer shows all files as having a size of 0 KB. Can this problem be fixed somehow? Thanks a lot in advance

Mhm, do you use file steam functions like „on demand files“ within you sync client? I m asking because as your files are very big, and so the on demand download might take a while as I assume this could be the reason for not showing their real size.

Do you have access to the cloud and can check, what the file size of the encrypted files is? You find them in your vault storage location, within the d directory. If they are big it shouldn’t be too difficult to find them.

When you open Cryptomator, activate Debug-Logging in the general settings, open the vault in question and copy such a video from the vault to an unencrypted location and lock the vault and close Cryptomator afterwards,

does the log file contain any WARNings or ERRORs ? You can also send me the log file via a PM, so we can look into this issue

But I can also send you the complete log file, thank you! However, I can’t see an option to send you a message on your profile…

I cannot copy the decrypted file, getting an error that the file is not available/does not exist.

The cloud provider is sciebo, this is a cloud run by a union of universities in the German region of North Rhine-Westphalia, used to store scientific data. The files are downloaded to the hard drive, as far as I can see, there isn’t even an on-demand sync option.

Before we start diggin through log files, lets see if the problem can be solved without it. The warning says, that the requested encrypted file has a size of 0 bytes. Is this correct? (i.e. check the file path)

If yes, then the content got somewhere missing between putting it in the vault (on some computer) and opening the vault on your computer.

Lina_Varonina:

cloud provider is sciebo

Ah, ok, I know them. They are using owncloud, so nothing special here.

What one can see is, that all(?) files throw the warning Unable to calculate cleartext file size for [FILEPATH]. Ciphertext size (including header): 0. Additional @Lina_Varonina explained, that the checked file path (and others) points actually to a directory and added the info, that on the first upload the vault could be opened but got reuploaded to the cloud a second time.

In our docs you can see that only (decrypted) symlinks or directories are encrypted folders with a .c9r ending.

If you browse through your files on the server (i.e. using the webinterface), point those filepaths also to directories?

On the cloud server, those paths also point to directories that are empty. In addition to these empty directories, the folder MR4ONUTBJ44EJWRTJQ3K57JIV3VW4C from the path above also contains several files the names of which end with ==== of size <1KB.

In all the other paths in d the .c9r files are indeed files and have seemingly proper sizes of (usually) several hundred MB.

On the cloud server, those paths also point to directories that are empty.

This leads to the conclusion, that either during the sync or placing the files into the vault something went wrong. For the first, check if the vault where this directory was created/modfied contains the video files and these can be played. If so, reattempt synchronisation.

For the second if sciebo offers a file history, you can restore an older verison of the affected directories. Otherwise, since there never was real data in the vault, the data is lost.

Lina_Varonina:

also contains several files the names of which end with ==== of size <1KB

If your decrypted directory also contains other files than big videos, these are them. The equal signs are just padding in the ecrpytion scheme. As long as these files end with .c9r you don’t need to be concerned.