CRITICAL - Directory ID reused

Hi,

Thanks very much for this software!

After updating from version 1.5.17 to 1.6.1 I also upgraded my vault to Vault Format 8. After running the Vault Health Check, I have a number of ‘CRITICAL - Directory ID reused’ errors but I can’t find any information about how to address these or what to do next.

sanitizer-0.16.jar cannot open Vault Format 8 so I am also not sure how to determine which decrypted files and folders these encrypted files refer to.

Thanks very much in advance for your advice!

CRITICAL - Directory ID reused: 7fd43ca6-5276-42e5-818e-27036d20a5d9 found in \d\3M\FVBT3C225GMP3DFUD3TKKQ33N53HZF\ulGvXMbURX1dNS4MS8IiawodaF8OGFTaqsE=.c9r\dir.c9r and \d\3M\FVBT3C225GMP3DFUD3TKKQ33N53HZF\Tnnc5ED-kyGzpgBtA3E3bmZNf9kLe8c9f96S2OiJMQ==.c9r\dir.c9r

2 Likes

Same problem here. Two entries with directory id reused

1 Like

Thanks for the confirmatory post @robman0815!

I’m relieved that I’m not the only one. As the sanitzer tool is not compatible with Vault Format 8, I had to manually work around this by making a complete copy of my encrypted vault to another location, removing the encrypted files for which there were duplicates, then mounting both vaults to two separate locations and using a tool to see which decrypted files were missing from the mounted vaults by comparison.

This was somewhat painful as a Vault Format 8 compatible tool/method to map encrypted files to decrypted paths would have been much more straightforward.

In my case, all of the duplicate IDs were from a ‘CRYPTOMATOR_RECOVERY’ directory which was made in the root of my vault.

All of the files in ‘CRYPTOMATOR_RECOVERY’ were already in my vault and decrypted successfully. Hence the duplicate IDs being reported?

It would be greatly appreciated if the Cryptomator team could respond. I have a supporter certificate and have purchased the Android app via Google Play.

Thanks very much for your help!

Welcome to the Cryptomator Community :slightly_smiling_face:,

CRITICAL - Directory ID reused ...

This error means, that there exists two resource names in the same directory pointing to the same subdirectory. This can be caused by faulty synchronization (e.g. renaming a folder but the sync client messes up and let the old/former one still exist).

One of the resources (a folder containing a dir.c9r file) can be deleted since they point to the same content, but Crypomator cannot decide which one.

If you are asking, how this is possible: Cryptomator flattens the encrypted directory structure and therefore needs to link parentfolders and their children. If now an encrypted folder is duplicated and renamed to a valid encrypted name, suddenly you have two “resources” in the same directory pointing to the same subdirectory. For more info, read about the security architecture of Cryptomator.

Hi @infeo,

Thanks very much for your reply. It’s greatly appreciated!

The context for how this happens is great. However, I can’t find any documentation on how to properly deal with this once it happens without my manual workaround as described previously.

My vault passes the health checks now but I couldn’t find any information about the ‘CRYPTOMATOR_RECOVERY’ directory which was created in the root of my vault or what to do about this?

Thanks very much for your help!

1 Like

This is not yet documented, unfortunately. The directory CRYPTOMATOR_RECOVERY contains, like the name suggests, recoverd directories (i.e. those, which dissappeared once). A directory can be recoverd by applying a fix in th the vault health check.

Thanks very much for your reply @infeo.

I have since manually resolved my issue but if there is any further information that I can provide to help debug this, please let me know. The ‘CRITICAL - Directory ID reused’ error messages which I received after upgrading my vault format were exclusively due to files in the CRYPTOMATOR_RECOVERY directory which were already in my vault and decrypted without issue.