Re: [sleuthkit-developers] ifind issue and library stuff.

[Brian C. <ca...@sl...>]

On Nov 28, 2006, at 6:34 AM, David Collett wrote:

> Hi Brian,
>
> I've attached a patch to check for a null pointer before free in
> fs_inode.c.  Michael Cohen added this. He can't remember if it
> definitely caused a crash or was just added while debugging something,
> nevertheless it doesnt hurt.

Thanks.  I'll add that in.

> The main reason for this email was to discuss an issue I found in  
> ifind.
>
> I have found an issue wherby if you have a file which has an allocated
> and an unallocated dent, ifind will often find the unallocated entry
> first and print '0' for the inode and return, even though there is an
> allocated inode with that filename, which is almost certainly what you
> want to see in this situation.
>
> This happens because fs_ifind_path issues a dent walk with ALLOC and
> UNALLOC flags set and the callback (ifind_path_act) stops walking as
> soon as it finds a name match, even if it is a realloc'd dent.
>
> A solution which seems to work is that when you find a name match,  
> check
> if you are alloc or unalloc (e.g. fs_inode->fsi == NULL seems to
> indicate unalloc), if unalloc, set found=1, record the inode (is it
> always 0?) but return WALK_CONT. This gives you another chance to
> find the real (alloc) file. If you then get to the end of the
> function without finding another one, you can print the details you
> have recorded (i.e. the unalloc entry). Does that make sense?

Yea. I'll make that change.
> On the topic of fs_ifind_path, I wanted to use this funtionallity in
> pyflag, but unfortunately if is very library unfriendly as it printf's
> the inode rather than returning it. What I did was rename this  
> function,
> modify it to return the matched inum, and then wrote a small wrapper
> version of fs_ifind_path which used the new function and printed the
> result in order to maintain the API. I think there are other places
> where this technique will be useful to me as I am writing a python
> sleuthkit module (for pyflag) and wish to employ sk in a library
> context. Would you me interested in patches for these changes? There
> have already been some great changes to help lib'ise sk (for example
> tsk_error stuff) I'd like to continue this effort.

Would it be easier if there was a callback design?

> Finally, I have unfortunately not had time to revisit the NTFS
> compression bug which I encountered as I have been mostly out of the
> office. I hope to look at it again later this week. Have you made any
> progress with it?

No.  I was waiting for someone to run a special version with verbose  
text output, but have not heard back.

thanks,
brian