Re: [sleuthkit-developers] unique identifier for TSK_FS_NAME

[Jon S. <jo...@li...>]

The primary use case is to have an identifier that uniquely identifies  
a TSK_FS_NAME record, which ideally would be compact and stable-ish  
(if the fs interpretation changed slightly, most records would be  
unaffected). The secondary use case is to give folks a pointer to  
where the relevant record may be on disk (e.g., MFT record), while  
obviously making allowances for filesystem variations.

My understanding is that a path may not be unique as a  
deleted&recoverable file may have the same path as an allocated file.  
There would be separate TSK_FS_NAME records but they'd have the same  
paths. (Please correct me if I'm mistaken in how tsk handles this  
situation.)

What I'd propose is an unsigned int in the TSK_FS_NAME struct, which  
would hold the byte offset of the record on disk, thereby  
distinguishing it. Not sure what to put for orphan files, but those  
are easy enough to determine, and we know they can be identified  
uniquely via the metadata address (right?). When in doubt, MAX_INT.

I don't need a lookup function, so no new functions or state, just  
adding another field to the struct.

Cheers,

Jon


On Jul 21, 2010, at 8:35 PM, Brian Carrier <ca...@sl...>  
wrote:

> Hi Jon,
>
> What is the use case for this identifier?  Are you saying that a  
> path is not unique because you could have the same path in different  
> file systems in a disk image? You could use the file system offset  
> as part of the path to make it unique?
>
> That being said, sure we could make an identifier for each name.    
> What should it report for orphan files though (files that have a  
> metadata structure, but no name)?
>
> brian
>
> On Jul 21, 2010, at 1:37 PM, Jon wrote:
>
>> Would it be possible to add a field to TSK_FS_NAME for the byte  
>> offset
>> of the record, either from the start of the volume or from the start
>> of the disk (whichever is easier)?
>>
>> "addr" works as a good unique identifier for TSK_FS_META structs, and
>> something similar for TSK_FS_NAME would be helpful. Paths aren't
>> necessarily unique, and a segmented scheme using the parent
>> directory's path/inum with the index number of the TSK_FS_NAME record
>> is not stable... a new version of TSK might figure out a way to
>> recover more files in a directory (hypothetically) and now the index
>> number may be shifted to a different record. Reporting the byte  
>> offset
>> of the record would be more stable and have the added benefit of
>> letting people quickly find the raw data in a hex editor, for
>> validation/inspection.
>>
>> Thoughts?
>>
>> Jon
>>
>> --- 
>> --- 
>> --- 
>> ---------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> sleuthkit-developers mailing list
>> sle...@li...
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers
>