Closed markuskreusch closed 7 years ago
Hello. I am having this issue on Ubuntu 16.04.2 LTS. Is there any way to bypass it? I cannot even delete the empty folder inside the vault (link) because it starts deleting the files & folders of the root directory. Is there a way I can manually delete the folder inside the encryted files?
You should be able to find this file using this command:
cd /path/to/vault
find d -type f -name 0* -size 0
By definition of Cryptomator's vault format, a directory file shouldn't be empty. Even though you should be very careful when modifying/deleting encrypted files manually, these files should be safe to delete. It would be more interesting to know how this file even came to be.
You should be able to find this file using this command:
I found the encrypted file corresponding to the empty directory (which acted as a link to root) before reading this answer. I used a graphical file explorer and checked at the modification times of the files/folders. Differently from what I expected, renaming the empty directory didn't change the modification date of the corresponding encrypted file. It changed only the modification date of the folder in which the encrypted file was.
By definition of Cryptomator's vault format, a directory file shouldn't be empty. It would be more interesting to know how this file even came to be.
The empty directory was inside the decrypted vault. When one creates a new folder, initially that folder is empty. When Cryptomator reads that folder and tries to encrypt it, something happens that creates a folders structure loop, basically the empty folder points to root folder.
Even though you should be very careful when modifying/deleting encrypted files manually, these files should be safe to delete.
To anyone who will have to deal with this issue in the future, having found the correct folder inside the encrypted vault, try doing this for each of its files. "Move file from encrypted folders to some other folder outside the vault. Refresh the decripted vault. If decripted vault is shown empty, move back the file where it was. Try the next file." Do this till you result in a not-empty-decripted-vault where the only folder missing is the one you wanted to delete.
Filename encryption is the relevant section to understand how folders work inside the vault format: https://cryptomator.org/architecture/#nameEncryption
A cleartext folder (created inside the virtual drive) consists of two things: A directory file and the ciphertext folder. The directory file is a pointer to the ciphertext folder (what we call directory ID). It can only be resolved with encryption (see how dirIdHash
is being determined).
The directory ID for the root folder is special and always empty.
That's why an empty directory file always points to the root folder. In a future Cryptomator update, this will be treated as an error, as stated in this issue. But even now, Cryptomator should never create an empty directory file. That's why I was curious how this even happened in the first place.
Maybe Cryptomator was able to create the directory file, but was unable to write the directory ID. If you know how to reproduce this issue, please let me know! And maybe look for errors inside the log file. It is located at ~/.Cryptomator/cryptomator.log
.
Filename encryption is the relevant section to understand how folders work inside the vault format: https://cryptomator.org/architecture/#nameEncryption
I'll look at that.
That's why I was curious how this even happened in the first place.
The case might one of these: Either the hdd free space was not enough (leading to an empty directory file) OR unmounting the virtual drive (GNU/Linux's case) without closing the vault from Cryptomator led to some process interruption...
And maybe look for errors inside the log file. It is located at ~/.Cryptomator/cryptomator.log.
Yesterday the log file was something like 32MB large. I planned to look at it today. It has been resetted... No valuable info inside.
I have another issue, noticed this morning which may be related (feel free to move this or create a new issue): I checked the size and number of elements in all the folders of my virtual drive (with Baobab in Ubuntu). I wanted to see if the was any other empty dir or folder loop yet to me unknown. There were some empty folders inside
Root ├NonEmptyDir1 │├File1 │├File2 │└File3 │ ├NonEmptyDir2 │├NonEmptySubDir3 ││├File4 ││└File5 ││ │├EmptyDir4 ││ │├EmptyDir5 ││ │├NonEmptySubDir6 ││├File6 ││└File7 ││ │├File8 │└File9 │ └NonEmptyDir7
EmptyDir4 and EmptyDir5 are not accessible by Baobab. This normally happens when it cannot read the files. EmptyDir4 and EmptyDir5 are accessible by Dolphin (file explorer) AND are shown empty. EmptyDir4 and EmptyDir5 did NOT create folder loops pointing to Root. File8 and File9, which are in the same parent folder as EmptyDir4 and EmptyDir5, are now disappeared. Those files (hundreds of images starting with "IMG-2015..." and "IMG-2016...") are not visible anywhere. Is there any way to 'dissect' the vault (having the key/masterkey file) in order to check where these files are gone and try to recover them? (log file already resetted, so not so useful).
You can check the vault's "health" with Sanitizer: https://github.com/cryptomator/sanitizer
Download the JAR file from here: https://github.com/cryptomator/sanitizer/releases And don't forget to check out the "Requirements" section form the first link. You need to have Java 8 and JCE installed.
Send us an email to support@cryptomator.org with your results and we'll continue the conversation there.
Ok. Just sent the email.
copied from https://github.com/cryptomator/cryptomator/issues/462
Basic Info
This is a
I'm using
I'm running Cryptomator in version: 1.2.3
Description
An empty directory file (mabe created through sync problems or other sofware interferring with cryptomator) is treated as a link to the ROOT directory. Regardless of how this happens such directory file should be treated as error, to prevent that external tools fail when doing directory listings.
Example (passphrase is asd): EmptyDirFileError.zip