I am using Cryptomator 1.3.4 on Windows 10.
My files are stored on an external harddrive and are encrypted by Cryptomator. The folder is uploaded to OneDrive.
I have copied all my files (around 200GB) to Cryptomator. All of the files were copied the following way:
Stored on locale storage
Copied to the cryptomator vault that is located on my external harddrive
All of the files got copied encrypted to my external harddrive by Cryptomator
Everything worked out fine except a lot of video files. It does not matter which type (mp4, mov, mkv etc.) nearly 50% of my video files are broken after I have encrypted them. I am not able to decrypt them and watch them again.
Some of the videos still have the same filesize and are broken.
Some of the videos have a lower filesize after encryption and are broken.
Some videos have no issues and are still working fine.
What I have done to “fix” it?
I have checked for the broken videos and copy&pasted them again into the vault. The file got replaced and encrypted again. After that the video worked. But this should not be the solution
Am I the only one having this issue? Or is this already known?
I am only facing this problem with video files. All of my other document types are working fine.
Im on the same environment and did some testing the last days by copying various video file up to 3gb each to several vaults synced with gdrive and onedrive.
I was not able to reproduce this behavior. All files were ok. Did not have any issues with a single one.
I think you can only reproduce this issue by copying several different file types.
In my case I copied around 150 GB of data at onces in my vault. This data consisted of mp4, wmv, mov, docx, jpg, png, pdf, ppt and and and and…
When I have noticed this issue and copied only the video files again they were all fine and not broken anymore.
due to the fact that I am still having this issue I tried to monitor it during the time. By now I think I can narrow it down to a certain behaviour. Maybe this helps you to find the bug. Otherwise what kind of information do you need in addition? Debugging-Mode Logs? Please tell me and I can try to provide you with that kind of information.
Now to my observations:
I can only reproduce this issue with videofiles that are .mp4 or .mkv. It does not matter how big the filesize of the video is.
I copy a videofile to my vault on Windows
The file gets encrypted and uploaded to the cloud
If I want to view the video on Windows within my vault I can open the file and watch the video. Somewhere in between it suddenly stops playing and the video seems to be finished, but it is not. For every different videofile the time when the video crashed is different. But for every same video it is the same frame again and again when the video crashes no matter how often I reboot my computer or restart Cryptomator.
3a. Funfact: When I try to watch the video on my iPhone or iPad Cryptomator-App it works completely. BUT, everytime I try to watch the video the app gives the following warning:
And there is always a video glitch at exactly the same frame when the video crashes/stopps playing on Windows. But the video does not stopp playing and continues correctly until the end of the video.
Due to the fact that the video plays correctly (beside the glitch) on Cryptomator-App it seems to me that there is a bug or a difference on handling decryption on the windows version for Cryptomator.
Beside videofiles I was also able to reproduce this issue with .NEF and . PNG. They did not work on windows but they worked within the Cryptomator-App
System
Windows 10 with Cryptomator 1.3.4
iOS 11.4.1 with Cryptomator 1.3.3
Cloudservice Onedrive
For a moment I was thinking that certain codecs or containers are causing this issue. But I have a folder with GoPro Videos. All of them are the same filetype. Some of them work without any issue and some of them show the described behaviour. So this could not be the reason.
I hope you can help me with my issue. Thanks a lot!
I tried to reproduce this on a Windows 10 Desktop with Cryptomator 1.4 beta2
I have 2 PNG Files within my vault, and unencrypted on local as well.
The unecrpyted files opens just normal (expected)
If I open the PNG Files directly in the vault (mapped with dokany) I experience a strange behavior.
Windows open the picture viewer and starts loading. Loooooong time. About 30-45 seconds later, the picture is shown. So I wanted to know if cryptomator is doing anything in this time period.
I closed the picture, opened the cryptomator App so see descryption speed, and openend the same picture again. Half a second later the image was shown. There was an expected small peak in the decryption graph, and thats all.
Then i opened the same image 6 Times (open/close). 2 Times the opening time was 30 seconds and longer. There were several decryption peaks in the graph. 4 times the png file was opened instantly.
So my suggestion is, that the reason for this behavior might be caused somewhere in the network connection of windows.
In your case, I assume that the copy process was somehow tampered with. Is there anything special on how you copied these files? The encrypted files were most likely manipulated, maybe even afterwards by an antivirus software. Or maybe even something with OneDrive, even though I haven’t heard a similar report yet. Does this happen without having OneDrive involved?
This is extremely hard to debug and I don’t think that Cryptomator’s debug logs would help that much because the manipulation most likely happened “from the outside” on the already encrypted files. By that, I mean the files in d/XX/YY/ZTNHM...II===.
But you can check out the log file and see if there is a more specific error message. You could also use Sanitizer to get a more detailed analysis. However, none of these methods will actually find the actual cause of the issue. Because when the manipulation on already encrypted data happens, it’s too late.
I remember a curious case when someone used Midnight Commander to copy a vault: https://github.com/cryptomator/cryptomator/issues/456
The copy mechanism “replaced all linux style line endings with windows style line endings which understandably breaks the encrypted files”. But I guess that’s not related to your issue since that would probably break all files.
In the past, authentication failures were detected in the desktop app as well (as you can see on the screenshot of the article I’ve linked). However, with 1.3.0 we made major architectural changes and that’s why the iOS app behaves differently in this case.
