Menu

#83 Better TskAuto error handling

closed
nobody
Auto (6)
5
2012-05-03
2012-02-27
No

Background: TskAuto tries to push its way through a disk image and as a result many error messages get dropped and ignored. There is a handleNotification() method now that gets some error messages, but there isn't a clear plan / policy on how someone implementing TskAuto should use it and it isn't being consistently called. We also have no way to really stop all processing if we hit some kind of really bad system error (I.e. it may stop processing a given file system, but it will then start processing then next volume). We also blindly reset some errors right now (I.e. VsWalkCB).

My main requirements for this system is that it is possible to stop processing entirely of an image and that all error messages can be recorded and later retrieved after the processing is done.

My proposal is:
* Add a class-level Boolean value that is set to stop all processing (ignore future volumes / file systems, etc.).
* Rename handleNotification() to registerError() and make the general requirement that when this method is called, that the TSK error values and strings will be set with an error to "register". The implementation of TskAuto is free to keep track of these errors as it sees fit. I was thinking about making a default version that kept a list of the errors and the error codes that could be retrieved after the processing was done.
* Document to users who implement 'processFile()' and 'processAttribute()' that they should also send their errors to registerError() so that they have a consistent reporting mechanism.
* Instruct users who implement 'processFile()' and 'processAttribute()' that they should only be returning CONT or STOP and not use the ERROR return value (or we could change the return value to only be one of those two options). Returning ERROR implies that processFile() and such set the global error values and in this case we don't want those to be processed by the lower-level code. If processFile() encounters an error, they should record the error with registerError() and then decide to continue or stop.

Thoughts?

Discussion

  • Brian Carrier

    Brian Carrier - 2012-05-03
    • status: open --> closed
     
  • Brian Carrier

    Brian Carrier - 2012-05-03

    Resolved in [master 58204fe]

     

Log in to post a comment.