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

[David C. <da...@in...>]

On Tue, Nov 28, 2006 at 09:13:36AM -0500, Brian Carrier wrote:
> >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?

Forgot to answer this last time...

On the one hand a callback seems overkill, but on the other hand it's
the only way to return multiple records, so I guess that could be
useful.

Having said that, do we ever actually want to return multiple records? 

A given path can only have one directory entry on most filesystems
(either allocated or deleted/unused), or two on NTFS where the second is
an artifact of b-tree balancing and is 'unused'. (is this correct?)

So the function should work as follows I think:
1. if an allocated dent is found, return its inode
2. if a deleted/unused dent is found, keep looking for an allocated dent
with the same name (which can occur in NTFS as described above). If
found, return that, otherwise return the (former) inode or 0 (filesystem
dependant) from the deleted/unused dent.

There is little value in returning both inodes in the second case as
this only occurs in NTFS (AFAIK), and the inode number is always 0 for
the 'unused' entry anyway.

Does that make sense?

Dave