Hi David,
Good catch. I added the "if (type == 0)" check and updated the API
docs to identify that 0 should be passed to use the default, which is
the same behavior as file_walk(). The compressed handling code is
fine because file_walk will choose the correct default type.
As an aside, the performance of the fs_read_file() API for FAT file
systems has been greatly improved in the next version. When a FAT
file is loaded, an internal runlist for its clusters is created and
maintained for the life of the FS_INODE. When you need to read from
inside of a file, the runlist is used to find where to read from
(instead of needing to read the FAT each time.
brian
On Dec 5, 2007, at 7:30 AM, David Collett wrote:
> Hi Brian,
>
> I've found a bug in fs_read_file_int in fs_io.c in sleuthkit.
>
> on line 410 it sets the 'type' of the ntfs attribute regardless of
> what was passed in to the function. This caused the function to fail
> when trying to read a particular attribute ($Extend/$ObjID:$0
> (25-144-2)) as the '144' was being reset to '128' and the lookup on
> line 421 failed as the attribute 25-128-2 did not exist.
>
> I think the solution is to simply surround the block (410-414) with an
> "if(type == 0)" check.
>
> Also, the compressed file handling on line 385 occurs before this
> block which assigns a default type, so it may be called with a type=0,
> is this ok? I think file_walk will just give you the default ($DATA)
> attribute if this is 0, but I cant remember for sure.
>
> Thanks,
>
> Dave
>
> ----------------------------------------------------------------------
> ---
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers
|
