Can you please elaborate what exactly happens when you attempt to open a file on Linux? Can you copy a file from the vault to your desktop and open it afterwards?
No, I cannot.
The problem is, where there should be folders, there is only a file of the same name (without any file extension) and of 0 kB size. So for instance, there should be a folder “Pictures” with lots of images inside, instead, I only see a file “Pictures” without any extension.
This is true for many folders inside the vault, but not all of them.
Sorry, I should have been more precise in my original post.
Which Cryptomator version are you using? Do you mount the vault via WebDAV or FUSE?
Version 1.4.7, using FUSE. The problem persists when mounting via WebDAV.
Can you please do the following:
- Unlock your vault and via in a terminal find the parent directory of “Pictures”
- Enable debug mode in Cryptomator’s settings
ls -lha /parent/of/pictures- Disable debug mode. The log should now contain debug messages of a single directory listing
- Send us the log, e.g. by uploading it via Firefox Send and sending me a PN in this forum.
Btw: Did it work correctly with 1.4.6?
I did as you asked. Please check your messages.
No, I did not work recently with 1.4.6. Strange though that the android app seems to get it right…
After analyzing the logs, we’ve found out, that several ciphertext files are just 36 bytes in size.
This is too small. The header alone is 88 bytes. Since Android is capable of decrypting them correctly, the cloud-stored files are still intact. This means you need to find out, why your synchronization software doesn’t sync the whole files. The problem here lies outside of Cryptomator.
Unfortunately, the cloud-stored files are exactly the same. I checked this via their web interface.
Also, I just downloaded an exact copy of all my files from the cloud service to a local device. The file sizes are the same.
Somehow, the android app is able to make sense of it all… Does that make sense?
Ciphertext files that are only 36 bytes in size can not exist. Without the 88 byte header it is impossible to decrypt the contents. Even older vault formats did not allow this.
Can you please log into the web interface of your cloud storage provider again and check the history of said file. Maybe there is any hint, what broke the files.
Therefore, the only logical explanation is, that there is a different reason why some files (that are greater than 88 bytes) are missing from the desktop app but present in the Android app.
So we’re dealing with two different and potentially unrelated problems here:
- Many ciphertext files have been damaged
- Some intact files are for different reasons not shown in the Desktop app
It is, of course, possible that the Android app is more resilient to damaged vaults, while a broken ciphertext file inside a directory may affect the whole directory in the desktop app.
@SailReal Or do you see any other possibility how the Android app can get a untampered copy of the ciphertext from cache/history/etc?
Or do you see any other possibility how the Android app can get a untampered copy of the ciphertext from cache/history/etc?
Right now, feature #48 and #24 is not yet implemented, because of that, each opening of a specific file leads to a new download.
while a broken ciphertext file inside a directory may affect the whole directory in the desktop app…
Long time ago but I think in the Android app, we implemented a “skip those kind of files”-mechanism.
I checked the file history inside the cloud storage:
The log shows that the small 36-byte files we discussed were created about half a year before I signed up for the cloud service. Which means, they existed before on my local drive when I was using cryptomator only for local drive encryption of my files. They then got uploaded much later to the cloud storage and have not been changed since. Could an older version of cryptomator have created these files? You seem sure that it could not…
More info on the data in the android app: I see all the correct files and folders, and everythind is accessible, as I said before.
However, I ALSO see the corrupt folders the way they appear in the desktop app. For instance, the desktop app shows a 0-byte file named “Pictures” where there should be a folder named “Pictures”. This is the same in the app, but the app also shows the correct folder “Pictures” with everything intact inside.
Does that help?
I am very grateful for all your help, thank you!
We need to keep on investigating this. At the moment I don’t have any explanation.
Thanks for your continuing efforts to retrieve my files!
I do hope that we can find a solution.
Thank you!
The 36 byte files seem to be a not correctly migrated directory file. We can manually fix this, however we should verify that the assumption is true. Can you please check the contents of one of the 36-byte-files? You should be able to open it in a normal text editor. It should look like this:
Thanks for getting back to me!
Yes, that is exactly what they look like. Alphanumerics in 8-4-4-4-12 groups.
Can you tell me, how many of these files exist? From within your vault directory, please invoke:
- correct directory files:
find d -type f -size 36c -depth 3 -name 0* - invalid directory files:
find d -type f -size 36c -depth 3 \! -name 0*
I tried the commands but I get an error message:
find: warning: you have specified the -depth option after a non-option argument -type, but options are not positional (-depth affects test specified before it as well as those specified after it). Please specifiy options before other arguments.
find: paths must precede expression: ‘3’
If I move the -depth 3 option before -type, I still end up with:
find: paths must precede expression: ‘3’
What should I do?
umm… maybe you need to quote "0*".
What does that mean? -depth 0* ?
Ok, find on Linux has different options than on a Mac. This should work now:
find d -mindepth 3 -maxdepth 3 -type f -size 36c -name 0*find d -mindepth 3 -maxdepth 3 -type f -size 36c \! -name 0*
You can send me the output via PN.