NTFS on-disk structure

[David.Cristian1987]

I am working at an application that recovers deleted files.
It is in a running phase, but I am trying to improve it, because I did
some
not okay decisions to make it work.

Given that, I want to know when I have reached the end of the
partitions.
More specifically, who tells me which is the last file on the
partition, or some kind of
an array of used file records (like the one in linux file systems like
ext3).

Thanks,
David

[robert...@yahoo.com]

On Jun 30, 4:21 pm, "David.Cristian1987"

Not sure I understand the question. The partition boundaries are
largely irrelevant if you're looking for bits of a file. In NTFS a
file starts with its MFT entry, which contains a list of "attributes"
for the file. Zero or more non-resident $DATA attributes define the
runs of clusters ('extents") containing the file's data. If you find
the deleted MFT entry (type=file and not marked in-use), you can
follow the list of attributes as usual. It's not really anything like
EXT3 in the way things are laid out.

There's a fair bit of useful overview at:

http://www.ntfs.com/

[David.Cristian1987]

On Jul 1, 6:35 am, "robertwess...@yahoo.com" <robertwess...@yahoo.com>
wrote:

Okay, I will be more straight forward.
I am parsing the file system structure and it seems all wright on D-
disk => if I delete a file the program sees it,
but when I parse the C: or the E: partition, it doesn't find nothing.
My stop condition is to test the first 4 bytes in the file record
It looks like that:
[code]
if(!memcmp(buffer, "BAAD", 4))
{
return BAD_CLUSTER_ERROR;
}
else if(!memcmp(buffer, x, 4))
{
return ZERO_CLUSTER;
}
if(memcmp(buffer, "FILE", 4))
{
return INVALID_MFT_ENTRY;
}
[/code]

And as I debugged the application I get to a point where this returns
INVALID_MFT_ENTRY, but I am sure that there are more files to be
discovered on the partition.
Is it something I didn't understand?
I got that we have all MFT entries after the boot sector, and then it
begins a part where I can find file records that are pointed by the
non-resident data-runs, mostly, if not all DATA attributes. The MFT
entries can be found somewhere else?

So why do I get junk in my file record if I haven't found all the
files on the selected partition?

Hope is clearer now and that u can help me :D.

Thanks,
David.

[robert...@yahoo.com]

On Jul 1, 9:59 am, "David.Cristian1987" <david.cristian1...@gmail.com>
wrote:

Sorry, still not very clear.

But, a couple of things appear wrong with your analysis. First the
MFT does *not* start after the boot sector, rather the boot sector
points to the first cluster of the MFT. You need to use that value
(bytes 48-55) and the number of sectors per cluster (byte 13 in the
boot sector), and the number of bytes per sector* (bytes 11-12), to
find the actual starting sector. FWIW, volumes formatted with Win2K
tended to have the MFT near the beginning of the disk (boot sector,
$Boot, $AttrDef and then $MFT). NT used a similar layout, except that
$AttrDef was allocated in the main part of the disk, so $MFT
immediately followed $Boot. WinXP and later tend to plop $MFT into
the middle of the disk (actually near the 1/3rd point).

Second, the MFT is not a single contiguous area. The MFT itself is
mapped by the $MFT MFT entry in MFT slot zero, with the typical
external attribute pattern. Other than the first 16 or so MFT
entries, they are *not* guaranteed to be in a contiguous region
(although they often are). Properly handling the $MFT MFT entry will
also let you determine the exact length of the MFT.

*Assuming 512 is pretty safe for now, but 4KB sectors are supposedly
coming soon. And you should really allow for different MFT entry
sizes (although I’ve never seen anything other than 1024 bytes).