Lost and Found .c9r Files at Drive File Stream

I’m uploading a 4tb vault to Google Drive via Google Drive File Stream.

The only solution that worked untill this moment was buying a new 4tb hard drive, and setting this drive as cache of Google Drive File Stream application for Windows.

Then inside of the drive provided by the application, create the encrypted vault.
All other tries with CyberDuck or MountainDuck where full of fails and errors.

Now at least its uploading. Err, not at all!

The Google Drive File Stream application begun to show me an error saying that ‘Some file couldn’t be uploaded, so it was put inside lost_and_found folder’.

The fact is that inside this folder there is already 2gb of files that I don’t know from wich folders on the Vault structure it was taken off.

I tryed to decrypt this files with sanitizer, but i have this error:

Exception in thread “main” java.lang.IllegalArgumentException: Unsupported vault version 7
at org.cryptomator.sanitizer.CryptorHolder.bestGuessCryptorProvider(CryptorHolder.java:91)
at org.cryptomator.sanitizer.restorer.VaultDecryptor.run(VaultDecryptor.java:32)
at org.cryptomator.sanitizer.commands.DecryptVaultRunner.run(DecryptVaultRunner.java:21)
at org.cryptomator.sanitizer.commands.DecryptVaultCommand.run(DecryptVaultCommand.java:91)
at org.cryptomator.sanitizer.commands.Commands.run(Commands.java:75)
at org.cryptomator.sanitizer.Sanitizer.main(Sanitizer.java:16)
at java.base/java.util.Optional.ifPresent(Optional.java:176)
at org.cryptomator.sanitizer.Sanitizer.main(Sanitizer.java:12)

Is there any idea on how can I found from wich folders on the vault structure, those files are taken off?

No. Indeed, the encrypted file name depends on its parent directory (see our docs), but this is not a reverse process (i.e. guessing from the file name to the directory).

Sanitizer is currently not able to decrypt files from vaults of format 7 or higher (introduced with Cryptomator 1.5.x). The overall plans are to integrate it into Cryptomator, see also this thread

1 Like

thats terrible. anyway, theres nothing I can do now, I guess?

so @infeo , at least when there is a new Sanitizer released, able to work with vaults of version 7, can I check the integrity of the vault and look from where this files are taken off? or at least that there is “X files missing from this folder:” or something similar?

or sanitizer also will not help me to solve from where those files are taken from?

This is also not possible.

Cryptomator only uses the directory id in the file name encryption process, but does not keep track of which file belongs to which directory. For this purpose an internal database would be needed, increasing the complexity of Cryptomator and leading to new bugs to handle (e.g. what if the directory structure is correct, but the database corrupte). And as a last point, from my point of view the behaviour of the sync client is just bad: Rather than moving the files somewhere else, it should directly refusing to upload the files.

yes, you are right @infeo

for sure its a google drive file stream failure in this case…
I’m still trying to solve it out.
I read at some Google Groups that File Stream will try to reupload it after the queue is complete. it still have 300gb to upload, so I’m waiting.

anyway, searching for the exact name from the files that are on lost_and_found folder, I can find their position on File Stream folder where the Vault is created. so maybe it hadn’t been moved, and just copyed.

searching for these filenames on Google Drive, I found archives in the exactly same localization as on the Vault structure, but with 0kb size.
and more, on lost_and_found folder, they have differente sizes from the Vault folder. always less than the original Vault file.

wich I can conclude from it is that, after I upload everything from the queue, I’ll reupload these files from original folders on Vault, to the same folder in Google Drive, and expect to everything be ok.
because if sanitizer wouldn’t work on this question, theres nothing much I can do except try this strategie and hope that everything is ok. or reupload those 730gb… :\

later on, I’ll come back here to tell everybody what happened…
thanks for your prestativity and attention @infeo

1 Like

To solve the topic I’ve lay here my solution for all this trouble.

After uploading everything to Google Drive using Drive File Stream, I went to lost and found folder, wich in windows is:

C:\Users\XXXXXXX\AppData\Local\Google\DriveFS\XXXXXXXX\lost_and_found

And copied the name of the files that was in this folder, to search on the “d” folder of the vault.

This way, the search bring me the exact location of each file, wich I had to mannualy reupload to vault in Google Drive. (using the location that the search on folder “d” at local vault returned).

It was just fine and take me only 30 minutes to do. The next part was a liitle bit more confusing and hard to solve.

One of the files in lost_and_found folder was a “dir.c9r” wich is widely repeated on a vault structure.

To solve out from where this file was taken, I had to open op the cloud vault on pc in WebDav mode, and use the app WinDirStat to find out that was one folder pointing to root of the vault. This folder was supposed to have 13 files inside, but when I get to this folder at vault, it used to bring me to the root vault folder.

I tried to rename or delete this folder, and renaming don’t resolve nothing, deleting will delete the whole vault. So, I solved like this:

Renamed the folder on cloud vault (mounting vault on cryptomator application while the files are located in File Stream drive), and checked on the Drive File Stream application to know wich file was renamed.
When sorted out, I just opent the folder that was renamed, and inside was a “dir.c9r” file without any data inside. I just copyed the data from the one tat was in lost_and_found, relaunched vault and voi-là, the structure was now perfect, the 13 files was showing correctly and everything was fixed.

Now I dont know what to do about uploading more 3tb for vaults in Google Drive. Since as I can see there is no application that could do this without lots of errors and failures.

Anyway, I let it here for someone that could face the same problem in future to solve it out by themselve.

Thanks @infeo and greetings from Brasil.

3 Likes