I’m seeking advice how to find out what happened and how to prevent that in future.
I’m converting from BoxCryptor. As such I copied >4500 files from Boxcryptor (Classic) to Cryptomator 1.5 with Dokany. I don’t know what you need to know to answer (e.g. if real filenames and folder names are important). So please ask.
Copying took place on one PC of mine. Data has been uploaded to DropBox and downloaded again on another PC. Finally I compared the new files with an old copy on the second PC. This may sound “expensive”, but:
In one subdirectory there’s a certain file of type PDF and two JPG, among others. When comparing files I realized that those two JPG files inside the (new) destination folder were identical to the PDF file (in content, length, time). Source files differ! How can this happen?
Then I tried to restore the JPG files from the source (copy over). Although the destination files could be deleted, the file manager failed to save them. The actual message might be specific to the behaviour of the file manager (it said, it cannot find the file - maybe it tried to save the file and then wanted to set attributes).
I had to lock the vault and unlock it again, before I actually could copy those files successfully.
Unfortunately, there’s no noticeable message inside the log file.
Hi everyone!
I have experienced something similar to @jeffrson.
First of all, I just wanted to say that i love Cryptomator and was so hyped to see this update.
Although, when updating the client to 1.5.0 and converting one of my old vaults i noticed that some files in the same directory had the same size which led me to use WinMerge to compare the “new vault” with my backup-folder and several files has now changed into other files in the same directory.
Example: File 5.jpg was still named File 5.jpg but was the same picture, size as File 3.jpg. The source File 5 was not to be found at all in the new vault! The same goes with other filetypes such as PDFs, doc etc. My sync- and backup program was disabled during the conversion.
I therefore tested this further and created a totally new empty vault and manually copied files from my backup (which had the correct files) into the new vaults, again several files “converted” into other files.
Another strange thing is that when I was using WinMerge several times on the same folder, other files started changing. I also tried using my backup program and files changed again!
Uninstalled/reinstalled both Crypto 1.5 and Dokany, no change.
Uninstalled and reinstalled Crypto 1.4.15, and everything works fine again.
I tried to reproduce that and here’s my story (conclusion at the end)
I also did a Winmerge check between my source files and the files in my vault.
And I detected the same issue. for example: the file “document1.doc” in the source was existing in the vault with same name but different content.
But what is also noticeable: in my case all these files have an very old timestamp. And I “love” to rename my files in order to keep the name-structure similar, and every now and then I decide that my actual structure should be changed
What I want to say: I’m suspecting my backup tool or my own behavior to cause this little “mess”, and not cryptomator. But I cannot say for sure obvious.
Actually I suspect my backup tool more than cryptomator.
So I just made the same comparison with my local backup storage (not encrypted by cryptomator).
And… same results, but less often and with different files than the check between source and vault. Another hint that the cause of this might not be cryptomator itself.
So, I decided to “clean up” my external USB-backups and my documents-vault and bring them to a state where WinMerge does not detect any differences between them and the source, so I can have an eye on that the next days.
I started with the external USB backup.
I deleted every file in the backup directory that did not match in binary and/or text with the same named source file. (This is a WinMerge function).
After that I started my backup process and checked for differences again. Result: no differences anymore.
Then I was heading to my vault and deleted also all not-matching files in the vault and started my backup-process. And was getting an error for every single file I have deleted in the vault and am now trying to copy back with my backup tool.
The log file (of the backup tool) says that there’s an error with the device where it wants to copy the file to.
System-Fehler: Ein an das System angeschlossenes Gerät funktioniert nicht (0x0000001F)
System error: A device connected to the system does not work (0x0000001F)
Hooray. Well, I’m still unsing WebDAV as interface (because it worked properly for me so far, at least I thought it would).
Maybe it’s time to switch to dokany.
Said and done and restarted the process: all files were copied properly into the vault.
So, I assume that my vault-differences are primary caused by me and WebDAV.
I’ll keep this under observation and will now and then do a winmerge check.
@Michael Thanks for the extensive testing! And on the plus size, you already did some spring cleaning (;
To be sure that there is no fault on the side of Cryptomator, @Ghoztie, can you do the same vault-creation-& copy-process again with debug mode enabled and send us afterwards the log files? (e.g. Mail or PM+FirefoxSend) If you additionally include a short list of names, where the file contents match even thou they shouldn’t, then it would be great.
unfortunately not in my case.
As I’m quite a while now on 1.5, even the “old” Logfiles do not show 1.4 entries anymore. (oldest available log April 19th, but already V1.5)
And I have to admit that I do not remember the names of the view affected files. So even If I could search them properly (why? Feature-Request soon), I would not know what to search for.
After “cleaning” up my vault I made several backup and sync processes (renaming, new files, deleting, editing), and my “match-check” still says that everything is ok.
update:
Today I did my tax return and therefore had a lot of movement in my documents.
After I did my backup (copy everything that has changed into the vault), I ran a WinMerge comparison.
I now have again a difference detection between my source files and the backups in my vault.
Interestingly the affected file is one that I’m sure I haven’t touched for years and havent touched it during my today operations.
WinMerge says the file names in source and vault is identical, the file content is completely different.
I opened the files via WinMerge and indeed, different files with the same name were opened.
Now it gets weird.
I closed the vault to make a backup of my log files for further investigation.
Then I opened the vault again because I wanted to know what is the content of the file in the vault that is actually shown by WinMerge as a different file. I wanted to know: which file is “right” and which is “wrong” in the vault.
I navigated to the directory of the affected files (both of them), and found every file 100% correct in the vault.
No mismatch between filename and content, everything is ok, nothing missing.
I was very confused, so I refreshed the same WinMerge comparison (completely) and: no differences anymore.
I checked the log files but I cannot see anything that explained this. (and there are many, many times the affected file is named in the log)
I closed Cryptomator, moved all the existing log files away, started Cryptomator, opened only one vault, and ran the comparison again (completely).
Surprisingly I had again a missmacht report by WinMerge, but with a complete different file (I’m also sure I havent touched id).
I closed cryptomator and saved the log files. @infeo : I will send you this log via Firefox with some more information about the file.
I then restarted cryptomator, opened the vault and told WinMerge to do a check only on this file. And the result was: files are identical.
I closed cryptomator and again saved the logs @infeo I will send these as well.
Maybe this will help you.
As the manually checks of the vault always had the result that everything is as expected, I must admit that I do not trust the WinMerge report anymore.
Still the question is: what might be the cause for that?
This is a vague hint (confirmed on GitHub) that the ciphertext files are all intact and the problem only occurs when showing the decrypted view. Which isn’t exactly good but still kind of comforting. Probably some issue with cleartext blocks cached in memory.
