[sleuthkit-developers] Re: IO Subsystem patch for fstools

[Michael C. <mic...@ne...>]

Hi Brian,

> I quickly looked the changes over.  Is there a need to pass FS_INFO to
> the read functions?  I didn't see you using them and it would be nice
> if we could avoid doing that (so that we don't have to restrict
> ourselves to file system code).
Good point, this is now fixed. read_blocks moved into the fs struct and the 
io_info struct is now free from all references to fs_info.

The major change now is that I implemented exception handling throughout all 
the libraries used by the io subsystem. I did not touch the rest of fstools 
for the moment, just until i get the general opinion from the list about this 
move, but in the long term I believe that all code should be converted to use 
exceptions, rather than calling error(). Exceptions make the code cleaner and 
easier to follow, and also make it possible to use this code as part of 
bigger pieces of code (e.g. as a python or perl module). I really need the io 
subsystem to be available as a python module for flag so I need good 
exception support in the iosubsystem code.

The swig interface has also been tuned to support exceptions in an intelligent 
manner and pass C exceptions to python exceptions seamlessly. Here is an 
example python session:

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import iosubsys
>>> io=iosubsys.io_open("ewf")
>>> iosubsys.parse_options(io,"off=32")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
RuntimeError: option off not recognised
>>> iosubsys.parse_options(io,"/storage/tmp/1.e01")
0
>>> iosubsys.read_random(io,100,0)
(100, '.... data chopped for briefness... ')
>>> iosubsys.read_random(io,100,10000000)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: Attempting to seek past the end of the file!
>>>

Here we see a python session using the iosubsys module, with an encase file of 
a floppy disk. When we try to set an option that is not supported (off=32), 
we immediately get a python runtime exception. This exception can be caught 
and an intelligent course of action can be taken by the python environment.

Similarly we see an IOError exception raised when trying to read past the end 
of file. Just out of interest, this is the C code that actually raises this 
exception: (line 377 in libevf.c):

if(chunk>offsets->max_chunk) {
    RAISE(E_IOERROR,NULL,"Attempting to seek past the end of the file!");
  };

All the underlying libraries support exceptions. At this stage I did not 
change any of the fstools themselves to handle the exceptions, so when a 
similar error occurs using the fls tool for example, its unhandled and causes 
the program to exit; pretty much the same behaviour as previously:

bash$ ../bin/fls -f fat -i ewf /etc/passwd
Unhandled Exception(IO Error): File format not recognised as EWF

Again the exception was raised from deep inside the library, but since it was 
not caught by anything it caused an unhandled exception termination.

Thoughts anyone?

Michael