Bug 432218 - Cannot Re-Use Vault Names
Summary: Cannot Re-Use Vault Names
Status: CONFIRMED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Vaults widget (other bugs)
Version First Reported In: 6.0.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: 1.0
Assignee: Ivan Čukić
URL:
Keywords:
: 459311 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-01-27 21:34 UTC by Rob H
Modified: 2025-01-15 22:51 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rob H 2021-01-27 21:34:34 UTC
SUMMARY
If you have a vault, use it, delete it, and then want to create a new one with the same name, you can't, the error: "Unable to perform the operation (error code 20)." I cannot find any information on what error code 20 is.

STEPS TO REPRODUCE
1. Create a new vault with a name,
2. Delete the vault,
3. Try to create a new vault with the same name in step 1.

OBSERVED RESULT
On the final step of creating the vault this error shows up:
Unable to perform the operation (error code 20).


EXPECTED RESULT
A new vault is created and able to be used.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch, 64-bit, up-to-date
KDE Plasma Version: 5.20.5
KDE Frameworks Version: 5.78.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION
Previous versions have the same issue.

After failing to create the vault and hitting cancel, the vault doesn't show up in the applet, but it does recreate the entry in ~/.config/plasmavaultrc. Deleting the the pointer to the .enc and deleted the entry from "EncryptedDevices" and deleting the actual .ENC file doesn't change the result. It also created the "~/.local/share/plasma-vault/rotbit1.enc/" folder and cryfs.config inside it.
Comment 1 nttkde 2021-11-08 13:27:09 UTC
Can confirm on KDE Neon User Edition.

I noticed files in ~/.local/share/cryfs/ don't get deleted at all when a vault is deleted, which might be the thing that blocks creation of new ones with same name.
When creating a vault with same name as an earlier deleted one, it created a new folder in cryfs/filesystems/ but didn't add it to the cryfs/basedirs file; perhaps because it existed there already.


Also, it looks like the entries in .config/plasmavaultrc are not removed correctly either.
I made an experiment:
If I create vaults 'test1', 'test2', 'test3' and then delete 'test2', its [/home/me/.local/share/plasma-vault/test2.enc] nor [EncryptedDevices] entries are NOT removed from plasmavaultrc.
If I then start to delete 'test1', at the point when its asking confirmation ("are you sure you want to delete this vault?") 'test2's entries get deleted. But confirming 'test1' deletion doesn't yet delete its own entries.
And if I then delete 'test3', at the confirmation dialog it has deleted the previous 'test1' entries, but 'test3' entries will stay.
Logging out doesn't make it go away either, and results in broken vault icon on the widget next login.
So it's some kind of one-off delayed removal from plasmavaultrc.

In any case the files in .local/share/cryfs were not deleted.
Files in .local/share/plasma-vault/ are deleted correctly.



Some of the state might be still incorrectly cached after file deletion, because when I manually deleted all the files, but didn't logout, it created an incomplete plasmavaultrc entry (the properties under [/home/me/.local/share/plasma-vault/test.enc] were missing). It also wasn't possible to delete the vault before logout, as it then complained about overlapping paths with some other vault.



So, to recap; to completely delete a vault I had to:
-from ~/.config/plasmavaultrc; remove its [/home/me/.local/share/plasma-vault/vaultname.enc] entry and the properties under it, and its entry under [EncryptedDevices]
-remove its entry from ~/.local/share/cryfs/basedirs, and the corresponding folder from ~/.local/share/cryfs/filesystems
-logout/restart to clear the cached state


Would be great if this got fixed.
Comment 2 Nate Graham 2022-09-22 17:35:03 UTC
*** Bug 459311 has been marked as a duplicate of this bug. ***