Re: [sleuthkit-users] A few NTFS questions

[Brian C. <bca...@at...>]

On Mon, Feb 10, 2003 at 03:33:38AM +0000, Chris Barbour wrote:
> I'm a little confused about fls' output regarding ntfs partitions, I get 
> lots of records with duplicate inode numbers with (realloc) appended to 
> the inode number. Where is the (ralloc'ed) meta data comming from? I'd 
> have thought the allocated file's metadata would have replaced the 
> realloc'ed one. Is it safe to ignore the realloc entries?

Yea, this is confusing (and not properly documented).  'fls' processes
the data structures that contain file names in them.  if the structure
has been flagged as deleted, then 'fls' will print "(deleted)" next to
it.  But, since the file name structure is different than the meta data
structure (inode or MFT for example), a file can be deleted and the
meta data structure re-allocated so that the resulting data is no
longer accurate to that file name.  Therefore, (realloc) is displayed
when a deleted file name points to an allocated meta data structure.
Of course, this does not detect when a meta data structure is
reallocated and then deleted again though.

On NTFS though, it gets worse.  NTFS stores the file name structures in
a sorted tree instead of a linear list (like FAT and FFS/EXT2FS do).  So,
when a file is deleted, its structure is not simply flagged.  It is 
removed from the tree and the tree is resorted (i.e. the files at the 
bottom of the tree get moved up).  So, when 'fls' runs on NTFS it
examines the tree to find structures that are not being used.  Quite
often though, the unused structure corresponds to a file that moved up
in the tree (and since the MFT entry is still allocated it comes up as
realloc).

The reason that I do not completely ignore them is because the file
name structure saves MAC times as well.  So, there could be a history
of times in the old structures.  But, the current design does not make
it easy to check for redundant entries.


> 
> On ntfs drives fls generates records that look like:
> /+ r/- * 0:    deletedregularfile/
> Inode 0 is the MFT on a ntfs drive so I assume inode 0 in this case 
> indicates the file has no inode surely this means the inode doesn't have 
> a file either!  Can these entries be ignored also?

These are useful to know that the file existed at one point, but for some
reason the MFT entry pointer was cleared so any dates and times that are
displayed with (-l) are not valid (and should say realloc).

brian