SUMMARY When cryfs cannot mount a directory, the vault UI will simply not show anything, so the user has no idea what's happening. STEPS TO REPRODUCE 1. Create a test vault and unmount it 2. Remove one of its binary files (eg. rm -rf Test\ Vault.enc/A6D/713C83A158E9483F5385E96AC219E) 3. Try to mount the vault using the plasma vault UI OBSERVED RESULT The UI closes without any feedback, as if the vault was properly mounted, when in fact, it did not mount. Trying to mount it from CLI shows: $ cryfs Test\ Vault.enc/ test CryFS Version 0.9.9 Password: Loading config file (this can take some time)...done [2020-04-22 11:08:13.960] [Log] [error] Could not load blob A6D713C83A158E9483F5385E96AC219E. Is the base directory accessible? [2020-04-22 11:08:13.961] [Log] [error] Crashed: Input/output error EXPECTED RESULT The Plasma Vault UI should at the very least show this error, being very explicit that the vault was unable to be mounted. Ideally, it would be nice to also show some additional information, like: - Full path for the blob (In the example, it would be ~/Test\ Vault.enc/A6D/713C83A158E9483F5385E96AC219E) - Possible suggestions on what the cause could be (incorrect permissions? maybe a conflict resolution by a shared service such as Dropbox? Hardware issues? etc...) SOFTWARE/OS VERSIONS Windows: No macOS: No Linux/KDE Plasma: Yes (available in About System) KDE Plasma Version: 5.18.4 KDE Frameworks Version: 5.69.0 Qt Version: 5.14.1 ADDITIONAL INFORMATION
In general, if cryfs crashed, than it is an upstream issue. I'd advise you to update to cryfs 0.10 as this issue has been resolved. If it happens again after the update, please reopen.
I disagree... the issue I am reporting is not that cryfs crashes, but instead that the UI does not provide any error to the user whatsoever. I agree that if cryfs crashes it is an issue that cryfs should fix, but in any case, the enduser does not care, he should know at the very least that his encrypted folder failed to be mounted, and get a minimum idea on why...
Thanks for the reply. I understand what you are saying and I agree that the end user does not care where the bug is. But Vault can not detect errors that cryfs does not tell it about. Vault reports all errors it gets from cryfs. Cryfs reports errors via return error codes. If cryfs does not report something as an error, Vault is not going to be able to show it to the user. In this case, cryfs crashes and reports an error through debugging output instead through the error codes as it should. And that *IS* an upstream issue. Grepping the output text is not something that could be used as an error detection mechanism reliably because the debugging output is not stable between backend versions and might depend on the active system language. While Vault can catch (and report to the user) many errors, it can not detect everything. It can only rely on the backend command to tell it what is wrong. Problems like this one would require to be handled on a case by case basis. If this was an issue that still existed in the current cryfs version, I would add some sort of a temporary hack to detect and report this problem to the user until the issue in cryfs was fixed. If you find a similar error with the latest version of cryfs, reopen this issue. P.S. While I really appreciate the discussion, it is not generally useful to reopen bug reports just because you disagree with a decision. The bug report status serves the developers to organize their work. If developers set the status to Fixed/Upstream, that means they consider the report to be a bug in an upstream product. If you change the status, that does not change the decision of the developer. It should go the other way round - you explain why you think an issue should be fixed, and the developer will then change the bug report status.
Thanks Ivan, I didn't know that the issue was that cryfs didn't return proper error codes. From your first response I understood you meant that newer cryfs wouldn't fail to mount the filesystem when there was a corrupted blob, and this is why I reopened the ticket... But now from your second response I get that they actually fixed returning proper error codes. I won't build cryfs from source, I will wait until a new release is made in the repo, the whole idea of my bug report was to improve UX/UI of Linux desktops for the general less tech savvy folk. Again, thank you for your time.