Re: [sleuthkit-users] A few NTFS questions
Brought to you by:
carrier
From: Brian C. <bca...@at...> - 2003-02-11 14:32:38
|
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 |