cryptomator / cryptofs

Java Filesystem Provider with integrated encryption
GNU Affero General Public License v3.0
94 stars 35 forks source link

Empty directory file treated as link to vault root #8

Closed markuskreusch closed 7 years ago

markuskreusch commented 7 years ago

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

ghost commented 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?

tobihagemann commented 7 years ago

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.

ghost commented 7 years ago

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.

tobihagemann commented 7 years ago

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.

ghost commented 7 years ago

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.

ghost commented 7 years ago

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).

tobihagemann commented 7 years ago

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.

ghost commented 7 years ago

Ok. Just sent the email.