Two folders but one set of files after renaming a single folder

Help Desktop App
1

I am a newbie to syncing files up to a “cloud drive” and to Cryptomator so please bear with me if this turns out to be a, yeah don’t do that, kind of issue.

I am on a Windows 10 machine. I am using Amazon Drive as my cloud service and have the latest version of their application installed and a folder identified on my desktop as the target to sync to.

I installed Cryptomator Version 1.3.1 and created a Vault within the Amazon Drive Sync Directory. I then created a new folder within the Cryptomator drive presented to me but I neglected to actually name it something other than the Windows default of, “New folder”.

I proceeded to copy a bunch of test files of various sizes and their associated sub directories into the “New folder” directory. I noted the encryption and syncing were all going on as expected and I left the copy run until it was done. (probably about 20 minutes)

When I got back to the console an hour or so later, all was as expected. The “New folder” contained all of the files I had copied over and my comparison to the originals was good. When I looked at the Vault folder in the Amazon Drive Sync Folder it too looked as described in the user manual.

Here is where I apparently did something I shouldn’t have.

Having finished the exercise, I decided to rename the “New folder” directory. I right clicked “New folder” in the Cryptomator drive and selected “Rename”. I typed a new name of “Test” in at the Name Change Prompt and then I closed Cryptomator by locking the vault.

Unfortunately, I am not sure how much time there was between the folder name change and the locking of the vault. I say this as I suspect this is what led to my situation.

This morning, some three days later, I reopened the vault. An Explorer window for the Cryptomator drive came up and displayed are two folders, one named “New folder” and one named “Test”. Each folder has the same number of files and takes up the same amount of space yet when I remove a file from either one, it disappears from both.

It’s like I have two different folder names with sub directory and filenames that match but only one set of files.

Can anyone explain what I did to get here or is this a bug of some kind?

2

This is indeed a rare behavior, you encountered. But I think I can explain what happened:

When you create a directory Cryptomator will generate a random directory id and writes it to a file inside your encrypted data (such directory files always start with a 0). This id is later needed to know what other files belong to said directory. The 0somethingsomething file is then synced to your cloud storage. So far, so good.

Now you renamed the directory, which causes the file to be renamed to 0somethingdifferent, but it still contains the same id. Because of sync delay or sync conflicts you ended up with both files. Those files will show up as directories, but since they contain the same id, they reference the same directory contents.

This is something we need to consider for a bugfix release, since it may harm your data: Since both directories are effectively the same, deleting one of them will destroy the other one.

:warning: :warning: :warning:

Of course, you can look for such files starting with a 0 and compare their contents with a text editor. Then delete any duplicates. However, we don’t really want users to do such things, as it is not only inconvenient but bears the risk of deleting the wrong files. :wink:

3

My apologies for not closing on this sooner.

Initially, I was not certain of your meaning of “files starting with a zero”. In looking back at this, I now realize you were referring to the Cryptomator Vault File structure.

In my points below, I was not looking at the Cryptomator Vault File Structure. I was looking at the decrypted file structure within the Explorer window for the drive presented by Cryptomator

Given the situation, I decided to delete the Vault and start over but I confirmed the following behaviors for you as I did so: (Again, these are WRT the Explorer File Structure on the decrypted drive presented by Cryptomator)

  • A file viewed from either directory looked the same, indicated size was the same and a binary compare matched.
  • Using Beyond Compare and a binary comparison rule, the two directories matched 100%.
  • If I deleted a file from one directory it disappear from the other directory at the same time.
  • If I opened a file in the one directory and made changes it the file in the other directory was changed too.
  • If I moved a file from one subdirectory to another subdirectory it moves similarly in the other directory.
  • When I deleted the one entire directory at the root of the Vault, the other directory wound up empty but the directory itself was still present in the root of the Vault.

I hope these notes help you to debug the issue and either fix it or generate a Best Practices Notice to users if it is really a general timing issue which seems impossible to provide a fix for.

4

I just upgraded my cryptomator < 1.5 to 1.5.3 and now see the same issue. I don’t find any 0… files which only contain IDs, but instead some encryped directories with a file “dir.c9r”. Should I scan those for duplicate contents and what happens if I find them? Can I just delete a folder with the dir.c9r file in that case?

I just did a quick check and identify that I currently have 56 c9r.dir files with duplicate ID in my nextcloud:

find . -type f -iname "dir.c9r" -exec cat {} \; -printf "\n" | sort | uniq -d | wc -l
56

where in total, I have 888 folders:

find . -type f -iname "dir.c9r" -exec cat {} \; -printf "\n" | wc -l
888

The 56 probaby matches the number of duplicate folders I currently have, they are all named NAME and NAME (1) and as already pointed out, if I delete one of those folders, the other one disappears as well.

5

Yes, since vault format 7, directory files are now called dir.c9r located inside a folder. See the changes on an actual example here.

Let’s check out this scenario:

.
├─ d
│  ├─ 73
│  │  └─ L6LNTEYQ55F5ECOWTMRDNQFHLKSZRH
│  │     ├─ 2tSaUkzXDEfe6fu3700xcIxYew==.c9r ← folder "NAME"
│  │     │  └─ dir.c9r ← directory file
│  │     └─ Eah1siezAbrwLIpqxYKT6Bn6fxIb-Q==.c9r ← folder "NAME (1)"
│  │        └─ dir.c9r ← directory file
│  └─ AF
│     └─ KZ54IJ5NTAK2VJUOSRSAKEITRXOLHK ← content of directory "NAME" & "NAME (1)"
└─ masterkey.cryptomator

We have two folders called NAME and NAME (1) with directory files that have the same directory ID (and are therefore duplicates).

Since you don’t know if 2tSaUkzXDEfe6fu3700xcIxYew==.c9r or Eah1siezAbrwLIpqxYKT6Bn6fxIb-Q==.c9r is the one with with (1) in the cleartext (since everything is encrypted), you have to make a best guess. Probably delete the longer one. Let’s say we’d delete the ciphertext folder Eah1siezAbrwLIpqxYKT6Bn6fxIb-Q==.c9r:

.
├─ d
│  ├─ 73
│  │  └─ L6LNTEYQ55F5ECOWTMRDNQFHLKSZRH
│  │     └─ 2tSaUkzXDEfe6fu3700xcIxYew==.c9r ← folder "NAME"
│  │        └─ dir.c9r ← directory file
│  └─ AF
│     └─ KZ54IJ5NTAK2VJUOSRSAKEITRXOLHK ← content of directory "NAME"
└─ masterkey.cryptomator

This would be the result then. In my opinion, it’s perfectly okay to delete a folder that has a duplicate directory ID in its directory file. But still, be very careful because editing/deleting something manually is prone to mistakes. If you haven’t already, make sure to have a backup strategy in place!

6

Hi Tobi,

Thank you for your explanations.

I tried deleting based on random guess with another small script:

find . -type f -iname "dir.c9r" -exec cat {} \; -printf " %p \n" | sort | { 
   prevId=none; 
   while read id path; do   
      if [ "$prevId" = "$id" ]; then      
	      echo "$path"; 
		  rm "$path";
      fi;   
	  prevId=$id; 
   done; 
}

That seemed to work. However, I found that I not only have duplicated folders, but for each folder, I had three “files” with the name of the folder or (1) (2)… appended. Those files, shown in windows explorer, were 0KB in size. I wasn’t able to delete them and when I tried to rename my (1) folder into its original name, without the (1), then windows explorer asked me to integrate that into the other “folder” what it presents to me as a 0KB file… Seemed very strange.

I now restored a backup from before the migration, setup my nextcloud to maintenance mode, deleted all file locks, activated it again, and let cryptomator migrate over night where I forbid my family to turn on their computers before cryptomator finished reuploading all 30GB of files. So far, everything seems fine but I’m a bit scared to let my family access nextcloud again, because they already have these corrupted files and nextcloud is probably going to upload them for all. So I will now perform another backup and if they mess up nextcloud again, I have to tell my family members that they need to delete their local nextcloud folder and resync from scratch.