https://bugs.kde.org/show_bug.cgi?id=420424

Ivan Čukić <ivan.cu...@kde.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |UPSTREAM
             Status|REOPENED                    |RESOLVED

--- Comment #3 from Ivan Čukić <ivan.cu...@kde.org> ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to