You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add an API to hand over/add an event listener to cryptofs. The event listener is bidirectional, i.e. does not only report but also returns a value. It is our decision to which events the listener is triggered (e.g. failed reading of a file, not existing directory, etc)
Problem Description
In cryptofs there are cases where it would be good to inform the caller about certain events/findings (e.g. files not belonging to the vault structure, invalid dir directories). Currently, only an error is thrown and the operation aborted or the event is logged, but otherwise ignored. From the caller perspective this is not the most desireable case, because with this you might miss (for you) important findings.
Solution
Expose in the API a method to add an eventlistener and then notify the listener on predefined events. The predefined events should be documented somewhere. For example there could be an extended method for filesystem creation, where one can hand over the event listener.
Alternatives
Collecting all occuring, not critical exceptions and then hand them over (in some way) to the caller. But this would require again some side channel.
The text was updated successfully, but these errors were encountered:
Summary
Add an API to hand over/add an event listener to cryptofs. The event listener is bidirectional, i.e. does not only report but also returns a value. It is our decision to which events the listener is triggered (e.g. failed reading of a file, not existing directory, etc)
Problem Description
In cryptofs there are cases where it would be good to inform the caller about certain events/findings (e.g. files not belonging to the vault structure, invalid dir directories). Currently, only an error is thrown and the operation aborted or the event is logged, but otherwise ignored. From the caller perspective this is not the most desireable case, because with this you might miss (for you) important findings.
Solution
Expose in the API a method to add an eventlistener and then notify the listener on predefined events. The predefined events should be documented somewhere. For example there could be an extended method for filesystem creation, where one can hand over the event listener.
Alternatives
Collecting all occuring, not critical exceptions and then hand them over (in some way) to the caller. But this would require again some side channel.
The text was updated successfully, but these errors were encountered: