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.
No, the files are downloaded to the hard drive beforehand and are completely syncronised when I try decrypting them
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.
I also tried to reproduce any cryptomator issue.
What I did:
- created a vault (dokany)
- created a 6,8 GB Video File (mp4)
- copied that file into the vault
- opened the file from within the vault
- closed the vault
- opened the vault again
- played the video file
- checked the size number of the file
Everything worked as expected
the size of the encrypted files in the cloud and on the hard drive is correct. the size of the d folder is >11 GB.
A locally created vault works for me as well, the problem seems to be with the data downloaded from the cloud
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 orERRORs ? You can also send me the log file via a PM, so we can look into this issue - and has the copied file also a file size of 0 ?
Additional questions:
- What is your cloud provider?
- Do you download the files or are you using features likes OneDrive FilesOnDemand?
I cannot see any errors, and the only warning that I can see in the log file is this:
13:45:56.434 [Thread-47] WARN o.c.c.attr.CryptoBasicFileAttributes - Unable to calculate cleartext file size for D:\phd\sciebo_daten\Main_Impact\WP2_Kinder\Feldstudie\Videoaufnahmen_Alexa\Videos\d\SI\MR4ONUTBJ44EJWRTJQ3K57JIV3VW4C\0NfnAxhFjYXivyjXHi2Ei6M=.c9r. Ciphertext size (including header): 0
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.
@Lina_Varonina I send you a PM, just answer it.
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.
Ah, ok, I know them. They are using owncloud, so nothing special here.
I looked into the sent log files.
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.
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.
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.