I'd like to specify a non-default icon for the encrypted folders (I try to set it manually to the folder-locked icon, so there is the effect of locked vs unlocked folders according to status). However, this creates a hidden .directory file inside the encrypted folder, after which it is not possible to decrypt the folder anymore (even though no error or warning is triggered), I assume because the folder has some content inside already, and decryption fails. This can be easily workarounded by deleting the hidden .directory file, that is coming back to the default folder icon. I know that this is not that important, but still, could we workaround this issue somehow?
This may be something that Vault needs to be able to tell Dolphin about using some .directory file in the Vaults dir. The file essentially would tell dolphin that subdirs are mountpoints and no files should be created in there while unmounted. On the other hand, Vault should be smarter and test if its mounted and if not, mount it.
Cannot Vault be smart enough to check if the only content is the ".directory" file just go ahead and mount it anyways? What would be the problem, perhaps that the original .directory would be lost? This could be workarounded perhaps by moving the original ".directory" file to a temporal destination before mounting, and then move it back right after unmounting. Not sure though if this would be considered a good solution.
Fuse (used by cryfs, encfs, etc.) does not want to use a non-empty mount point. It can be overridden, but I really do not see this as a valid use-case for doing a force-mount.
Fair enough. Would be good to raise a notification of the underlying reason why mounting was unsuccessful though, so the user knows what is going on.
When you try to mount, and when it fails, you should get a message in the newly opened password entry dialogue that "The mount point directory is not empty, refusing to open the vault".
Nice! Is this something recently added? Asking because I don't see that behavior in plasma 5.11.1 (plasma-vault 5.11.1-0neon+16.04+xenial+build5)
To be more specific... When mounting fails in my system, there is no newly opened password entry dialogue, it just fails quietly.
What backend did you use?
(it is not new - the password dialogue should not close on error)
> What backend did you use? I use CryFS. > (the password dialogue should not close on error) Ok, then. The password dialogue does close in my system. (Using: ii plasma-vault 5.11.2-0neon+16.04+xenial+build6)
Can you re-test the latest version?
(In reply to Ivan Čukić from comment #11) > Can you re-test the latest version? It works now. Thanks!
Sorry I talked too fast. I almost forgot what the issue was about and the test I did was not proper (I just tested introducing a wrong password, and the dialog remained opened and properly informed about the incorrect password). But this issue was about trying to mount the content on a non-empty folder. To test this, I modified the icon of that folder to put one with a locker. That generates a .directory file so that folder is not empty anymore. I think the issue is still present because when I tried to mount, no error was reported, the dialog disappeared, and dolphin was open, but no content was mount (just the .directory that was created because of the folder icon change). To mount against a folder that only contains a .directory file was not considered a plausible use-case, which is fair. However, failing to mount should be reported, which is not yet the case. I reopened the issue according to the new test I made. I hope it is ok.
Tested in plasma-vault 5.12.2 (KDE neon User Edition)
Ok, great. I know what the problem is. Will have to wait for the new release of CryFS and Plasma for this to be fixed though.
Sounds good, thanks!
This is fixed in 5.13 and cryfs 0.9.9
Thanks! I'll check this out as soon as cryfs 0.9.9 is available in my system... (In reply to Ivan Čukić from comment #17) > This is fixed in 5.13 and cryfs 0.9.9