Concept - File Record

Overview

The MFT is a set of FILE records. Each file of the volume is completely described by one or more of these FILE Records. File Records are equivalent to inodes in Unix terminology. The first FILE Record that describes a given file is called the Base FILE record and the others are called Extension FILE Records.

A FILE Record is built up from a header, several variable length attributes and an end marker (simply 0xFFFFFFFF).

link table to notes

See also: Attributes, Standard Attribute Header, $MFT, $Boot, File, Fixup, Attribute Id, Directory,

Layout

FILE Record

Header

Attribute

Attribute

...

End Marker (0xFFFFFFFF)

(a) The offset to these two fields depends on your operating system.

$LogFile Sequence Number (LSN)

This is changed every time the record is modified.

Sequence Number

Number of times this mft record has been reused.

N.B. The increment (skipping zero) is done when the file is deleted.

N.B. If this is set to zero it is left as zero.

Hard Link Count

Number of hard links, i.e. the number of directory entries referencing this record.

N.B. Only used in mft base records.

Flags

Flag	Description
0x01	Record is in use
0x02	Record is a directory
0x04	Don't know
0x08	Don't know

Real / Allocated Size

The Allocated Size is how much space the Record takes up on disk. This should be a multiple of the cluster size and should probably be equal to the size of an MFT File Record. The Real Size is a count of how many bytes of the Record are actually used.

N.B. The Real Size will be padded to an 8 byte boundary.

Base MFT Record

This is zero for Base MFT Records. When it is not zero it is a MFT Reference pointing to the Base MFT Record to which this Record belongs. The Base Record contains the information about the Extension Record. This information is stored in an ATTRIBUTE_LIST attribute.

Next Attribute Id

The Attribute Id that will be assigned to the next Attribute added to this MFT Record.

N.B. Incremented each time it is used.

N.B. Every time the MFT Record is reused this Id is set to zero.

N.B. The first instance number is always 0.

The master file table record consists of a header and the attribute list. It has a size of 400 (=1K), or the cluster size (whichever is larger). The header has the following fields:

Notes

The attribute list is of variable length and terminated with FFFFFFFF. For 1K MFT records, the attribute list starts at offset 0x30.

    The sequence number is a circular counter (skipping 0) describing how many
    times the referenced mft record has been (re)used. This has to match the
    sequence number of the mft record being referenced, otherwise the reference
    is considered stale and removed (FIXME: only ntfsck or the driver itself?).

    If the sequence number is zero it is assumed that no sequence number
    consistency checking should be performed.

    FIXME: The mft zone is defined as the first 12% of the volume. This space is
    reserved so that the mft can grow contiguously and hence doesn't become
    fragmented. Volume free space includes the empty part of the mft zone and
    when the volume's free 88% are used up, the mft zone is shrunk by a factor
    of 2, thus making more space available for more files/data. This process is
    repeated everytime there is no more free space except for the mft zone until
    there really is no more free space.

    The mft record header present at the beginning of every record in the mft.
    This is followed by a sequence of variable length attribute records which
    is terminated by an attribute of type $END which is a truncated attribute
    in that it only consists of the attribute type code $END and none of the
    other members of the attribute structure are present.

    When (re)using the mft record, we place the update sequence array at this
    offset, i.e. before we start with the attributes. This also makes sense,
    otherwise we could run into problems with the update sequence array
    containing in itself the last two bytes of a sector which would mean that
    multi sector transfer protection wouldn't work. As you can't protect data
    by overwriting it since you then can't get it back...
    When reading we obviously use the data from the ntfs record header.
    

The sequence of attributes part

This is a sequence of file attributes that has a variable length. In each FILE record, the sequence is ordered by increasing order of the attribute type. The sequence is terminated with FF FF FF FF.

    Size defined in $Boot.
    A FILE record is 1 KB large or the cluster size if larger (as far as Helen is
    concerned, its maximum size is 4 KB, but Windows NT 4 limit is 64 KB). It falls into
    2 parts:
    

Extension FILE records are used when all information about a file doesn't fit into the base FILE record (e.g. if the sequence of file attributes grows because the file has a lot of file attributes or because the data attribute of the file has a long runlist because its stream is very fragmented). Only the base FILE record is used for referencing the file it describes. Since the type of the Attribute List file attribute is small enough, we are sure that this file attribute will be in the base FILE record. And this file attribute provides the references to all the extension FILE records describing the file.

When a file is deleted, NTFS can't simply remove the associated FILE records from the MFT, otherwise FILE record numbers wouldn't be constant over time, and all file references would have to be updated! Instead, the in-use flag of a FILE record indicates when it is no longer in use. When a file is created, an unused FILE record can be re-used for it, but its sequence number is incremented by one. This mechanism allow NTFS to check that file references don't point to deleted files.

    seq num = inode for 0x00 < i < 0x10 (inode 0 (MFT) has seq num of 1)
    

    see also attribute id page and file reference page
    

    flags 1 in use, 2 dir, 4 ???, 8??? (4+8 ARE used)