I have a folder with sub folders that cannot be deleted. I have tried the cmd del function to no avail. I cannot delete the folder\files in the native Cryptomator structure as I have no idea what encrypted name it is and I am not sue what would happen to Cryptomator if I knew the structure name Some common utilities I could try do not support virtual drives so they are not even listed for me to try and use 3rd party software. I have done a scan on the physical drive itself hoping something was amiss with the directory index and it would do a “repair” but that did not find any errors.
In just using explorer I right click on the folder and select delete ant it gives the standard prompt do you want to permanently delete the file and I say yes and it appears it works but the folder is still there. I tried deleting all of the subfolders first and the same happens.
Any application that allow you to drill down to virtual drives behaves the same way as if it deletes the file but it is still there.
I am hesitant to ignore the file folder\file and let it remain forever but that makes me uncomfortable that something somewhere at sometime is going to throw some error when I least expect it. If I have to copy all content from my Cryptomator folder to a new Cryptomator folder and ignore that one folder\file will take 10-20 hours as the folder is 2.7TB. However, it feels like I am at a complete lost.
I am really hoping there is some reverse tool that Cryptomator allows me to point to a folder\file and it will tell me what is the actual file name in the encrypted state and I could try it delete it as a standard drive structure. However, even if something would tell me what the encrypted name is I don’t know what it would do Cryptomator who realizes some folder\files have disappeared
Hi. Which volume type are you using? WebDAV? Dokany? WinFSP? Did a change help?
Anything suspicious in the log file (WARN or ERROR) records when you try to delete this folder?
If you vault is online, you can also try to access it with cyberduck and try to delete the folder.
I was using Dokany. I did not trying change that to see if it would help as I continued to explore other applications installed on my desktop. Thank goodness for Free File Sync which has an option to delete and move files to the recycle bin. For some reason Free File Synch among all other applications was able to delete the folders and move them to the recycle bin. Why I am not sure?
I suspected that Free File Synch may have had a hold on the folders\file from previous use. However, I don’t see how that it is possible because I have done multiple reboots since I used it last. Unless there is some file stored which is somehow referenced on relaunch so even after reboots it somehow can reinstate its hold. I don’t think that is logical but possibly the capability exist or the other option is Free File Synch somehow handles deletes of locked files different than others. Anyway, it is resolved as the folders have been moved safely to recycle bin.
I cannot say enough great things about Free File Synch either way.
Thanks for your follow-up and reply. Hopefully, this might be helpful to the next person who runs into such a scenario. Something I have never seen, although there are posts on the Internet where it states it is a common problem. The first for me though.
In Cryptomator 1.7.x the “reveal encrypted file” feature was added. Instead of deleting the directory inside the unlocked vault, you can also delete the (encrypted) directory in the vault storage location, by using the feature.
But due to a feature of Cryptomator you would not delete it’s subdirectories. After deleting a encrypted directory directly at the vault storage location, all subdirectories will be become inaccessible and must be readded to the vault-internal filesystem with running the health check and fixing all “orphan” results.