Hello,
about the robustness, cryptomator is after all created to work with the cloud.
Once I really overdid it (had nothing to lose) and I don’t blame anyone, but the robustness would have to be checked.
I deleted over 20GB of data from the local vault, also interrupted the sync to Nextcloud, can’t wait forever for everything to sync, also shut down the PC mercilessly. The local vault was cleaned as desired, but the result was blocked files in the Nextcloud mysql-DB, all relevant web file folders nicely filled with useless data and I was allowed to clean up the mysql-DB and the file system manually, nice exercise, but not for everyone.
So again in short: the local vault was cleaned as requested, but in the nextcloud the vault was as big as when I started and I had blocked files in the mysql DB and the trash and versions folder were full.
Greetings
You could probably reproduce this Nextcloud error without even using Cryptomator. I would suggest to try to reproduce this without Cryptomator (not sure if it that’s easy but along the line “delete XGB of data, interrupt Nextcloud sync, and shut down PC mercilessly”) and report the bug to Nextcloud.
again, I do not blame anyone, I did it out of curiosity and wanted to test the robustness. Normally, you delete files, sync completely in one piece and that’s it, especially with sensitive data in the vault. My test regarding robustness says it all, robustness that is.
And yes, I do that often, delete GB’s of data from the normal local Nextcloud folder - no matter what I do, when the local sync client stops, no matter how, the sync stops too, it’s obvious, always worked until now; sometime after days the sync was done without me even thinking about it.
Somehow it seems that Cryptomator is not so robust here. Files are completely deleted from the vault locally yes, but on the server they were marked as blocked in the mysql DB, whatever, but not deleted. I still had the 20GB blocked in Nextcloud weeks after and nothing happened.
I do not know the inner workings of Cryptomator, just recommend a similar test.
And to the other users, I would advise against such crude behavior. (I mean my behavior)
I’m using Nextcloud myself with >400GB cryptomator files for years and had never serious problems.
Sure, no software is always error-free, but I regularly verify my data with diffs and I would notice something like that. Where I stumbled across more than once is the problem of DeadlockException executing UPDATE `oc_filecache` · Issue #22482 · nextcloud/server · GitHub but so far it has not led to any data loss for me either.
Have you looked at your Nextcloud log, did it give you any helpful messages?
I came to my conclusion because Cryptomator doesn’t “connect” to any cloud storage service (e.g., Nextcloud). Cryptomator “just” performs typical file system operations like read, write, move, delete. If you delete files inside the virtual drive, Cryptomator performs delete operations on the encrypted files. If the encrypted files are located in a synced folder handled by Nextcloud, it’s the job of the sync software to handle those deletes properly. That’s why I suggested that this issue should also be reproducible without Cryptomator.
It’s not about blaming anyone, I understand that. 
I just wanted to give some insight from a technical perspective. I still believe that it would be easier to debug this issue if you try to reproduce it without Cryptomator and report the bug to Nextcloud. Of course, you can also post your findings here if Cryptomator’s delete pattern somehow makes this issue more likely.
@ SailReal
Why am I actually posting here?
I am trying to find out why Cryptomator “drags along” directories in “d” (I see them filled with files in the Windows file system, but the contents are not displayed in the open vault), that should no longer be in the vault.
If I have a directory in “d”, e.g. “5F” with 5GB, but the directory does not show the contents of 5GB in the open vault, then something is not correct.
I suspect that Nextcloud did not delete the files because they were still in Cryptomator.
If Cryptomator simply goes and deletes everything from the vault after a request, which is not shown in the open vault anyway, then it would probably look different. I just don’t know.
And yes, I had added in the MySQL DB to
- oc_activity
- oc_filecache
- oc_files_trash
…
thousands of entries that seemed superfluous to me.
I stopped any activity to Nextcloud, switched to maintenance mode and searched in phpMyAdmin with
e.g.:
SELECT * FROM ‘oc_filecache’ WHERE ‘path’ LIKE ‘%ncr…%’
and deleted with
DELETE FROM ‘oc_filecache’ WHERE ‘path’ LIKE ‘%ncr…%’
I also searched for ‘file’ and similar regarding Cryptomator folder.
And I deleted everything from the Nextcloud data file system regarding Cryptomator.
After that I started again with a new vault. Then everything was OK again.