The Master File Table, written $MFT on disk, is the index that NTFS uses to keep track of every file and directory on a volume. It is the first user-visible file on every NTFS partition, and every other file on the volume — including the table itself — has at least one entry inside it. Reading $MFT is how forensic tools answer questions about files Windows no longer admits exist: when they were created, what they were named, what they contained, and who touched them last.
This guide is a complete reference. It covers what the table is, how records are laid out, which attributes a record can carry, the small set of reserved system files at the start of the table, what "Windows cannot recover the master file table" actually means, and how to read $MFT yourself with the parser on this site.
What is the Master File Table?
The Master File Table is a single file named $MFT that sits at a fixed location near the start of every NTFS volume. NTFS — New Technology File System — was introduced with Windows NT 3.1 in 1993 and replaced FAT as the default Windows filesystem. Unlike FAT, which keeps a small allocation table and stores filenames inside directory entries, NTFS puts almost every piece of metadata about every file into one structured table: $MFT.
Each row of that table is a record that is exactly 1,024 bytes long. Each record describes one file or one directory. The record holds the file's name, its timestamps, its DOS-style flags, the list of disk clusters where its data lives, security descriptors, and a handful of other attributes — all encoded as a small bag of typed fields.
This design has two big consequences:
- All metadata is in one place. A single seek to
$MFTis enough to enumerate every file on the volume. Forensic and recovery tools depend on this; so do antivirus scanners and indexing services. - Deleted files leave intact metadata behind. When NTFS deletes a file, it clears one bit in the record header and marks the file's clusters as free. The rest of the record — the name, the timestamps, often the data runs — stays put until that record slot is reused.
The acronym MFT stands for Master File Table. You will see it written as MFT, $MFT, or the MFT. They all refer to the same on-disk structure.
How $MFT is laid out on disk
When NTFS formats a volume it reserves a region called the MFT zone near the start of the partition. The boot sector at offset 0 of the volume contains a pointer (the MftStartLcn field) to the first cluster of $MFT. The first 16 records of the table are reserved for NTFS metadata files (described below); record 0 is the table's own entry, pointing back at its own clusters.
$MFT grows by extending into its reserved zone whenever it needs more records. If the volume fills up before the zone is exhausted, Windows shrinks the zone to make room for user data, which is why a heavily-fragmented $MFT is a common symptom on aging filesystems.
A backup of the first few records lives in a second file, $MFTMirr, usually placed in the middle of the volume. If $MFT itself is corrupted, NTFS uses $MFTMirr to bootstrap recovery — this is the mechanism behind the "Windows cannot recover the master file table" error described later.
Anatomy of a FILE record
Every MFT record begins with the four-byte ASCII signature FILE. (Corrupt records use BAAD instead — a deliberate tombstone written by chkdsk.) After the signature comes a fixed header, followed by a stream of variable-length attributes.
The record header carries:
- Signature —
FILEfor a valid record,BAADfor a recordchkdskcould not repair. - Update sequence number (USN) and fixup array — a tiny checksum trick that lets NTFS detect torn writes. The last two bytes of every 512-byte block in the record are replaced with the USN; the originals are stashed in the fixup array. On read, NTFS verifies the USN and restores the original bytes.
- Log sequence number — a pointer into
$LogFilefor crash recovery. - Sequence number — incremented every time the record is reused. Combined with the record number it forms a 64-bit file reference that uniquely identifies one specific incarnation of a file.
- Hard link count — number of
$FILE_NAMEattributes pointing at the record. - Flags — the most important one is bit 0,
IN_USE. Clear means deleted. - Base file record reference — non-zero on extension records that belong to a base record elsewhere in the table.
After the header come the attributes. Each attribute has its own short header (type, length, resident/non-resident flag, name if any) followed by the data. There is no fixed order, but $STANDARD_INFORMATION is conventionally first and $DATA last.
A record that runs out of space — too many fragments, too many ADS, an unusually long name — sprouts an $ATTRIBUTE_LIST attribute that points at one or more extension records elsewhere in the table. Parsers must follow the chain to assemble the complete file.
File attributes stored in $MFT
This is the most common search behind the keyword "what file attributes are stored in the master file table". The full list of NTFS attribute types, with hex codes:
| Type | Hex | Purpose |
|------|-----|---------|
| $STANDARD_INFORMATION | 0x10 | Four timestamps (created, modified, accessed, MFT-modified), DOS flags, owner ID, security ID, USN. |
| $ATTRIBUTE_LIST | 0x20 | Pointer to extension records when a file's attributes overflow one record. |
| $FILE_NAME | 0x30 | A filename, parent directory reference, allocated and real size, and a second set of four timestamps. A file may have several — one per hard link, one for the 8.3 short name. |
| $OBJECT_ID | 0x40 | 128-bit object identifier used by the Distributed Link Tracking service. |
| $SECURITY_DESCRIPTOR | 0x50 | Legacy per-file ACL. Modern NTFS stores ACLs centrally in $Secure and references them by ID from $STANDARD_INFORMATION. |
| $VOLUME_NAME | 0x60 | Only on record 3 ($Volume). Holds the volume label. |
| $VOLUME_INFORMATION | 0x70 | NTFS version, dirty flag. |
| $DATA | 0x80 | The file's contents. Resident for very small files; non-resident (a list of cluster runs) otherwise. A file can carry several $DATA attributes — the unnamed one is the main stream, the named ones are alternate data streams. |
| $INDEX_ROOT | 0x90 | Root of a B+ tree. Used by directories ($I30), reparse-point indexes, and other indexed structures. |
| $INDEX_ALLOCATION | 0xA0 | Non-resident continuation of a large index. |
| $BITMAP | 0xB0 | Allocation bitmap for $MFT itself or for large directories. |
| $REPARSE_POINT | 0xC0 | Symlinks, junctions, mount points, OneDrive placeholders. |
| $EA_INFORMATION / $EA | 0xD0 / 0xE0 | OS/2-era extended attributes. Rare on modern Windows. |
| $LOGGED_UTILITY_STREAM | 0x100 | EFS encryption metadata ($EFS), TxF transaction data. |
A record always carries at least $STANDARD_INFORMATION, one $FILE_NAME, and one $DATA. Everything else is optional and feature-driven.
Resident vs non-resident data
Most $DATA attributes on a real volume are non-resident: the attribute header carries a compact list of cluster runs (a starting LCN plus a length, repeated), and the file's bytes live elsewhere on the disk. The attribute header itself is small.
If the file is small enough — typically under ~700 bytes after the other attributes are accounted for — NTFS stores the bytes inline inside the record. That is resident data, and it is one of the most useful artefacts in forensic work: the contents of a small text file deleted weeks ago may still sit, byte-for-byte, inside an unallocated $MFT record. See resident-data for a deeper look.
NTFS metadata files in the first sixteen records
The first 16 records of $MFT are reserved for NTFS's own bookkeeping files. They start with a $ so they don't collide with user filenames. The ones worth knowing:
| Rec # | File | What it is |
|-------|------|------------|
| 0 | $MFT | The table itself. |
| 1 | $MFTMirr | Backup of the first records of $MFT. |
| 2 | $LogFile | Transaction log used to undo or redo incomplete operations after a crash. |
| 3 | $Volume | Volume label and dirty flag. |
| 4 | $AttrDef | Schema of valid attribute types. |
| 5 | . | The root directory. |
| 6 | $Bitmap | One bit per cluster on the volume; tracks allocation. |
| 7 | $Boot | Copy of the boot sector. |
| 8 | $BadClus | Sparse file whose runs point at every cluster the filesystem has marked bad. |
| 9 | $Secure | Central store of security descriptors. |
| 10 | $UpCase | Unicode upper-case mapping table used for case-insensitive name comparison. |
| 11 | $Extend | Directory containing newer system files: $ObjId, $Quota, $Reparse, $UsnJrnl, $RmMetadata. |
The change journal $UsnJrnl (under $Extend) is especially useful in forensics — it logs every metadata change on the volume and complements $MFT for timeline reconstruction. See usn-journal.
When $MFT goes wrong: corruption and "Windows cannot recover the master file table"
The error message "Windows cannot recover master file table. CHKDSK aborted" appears when chkdsk cannot read $MFT and cannot fall back to $MFTMirr either. By the time you see this message, NTFS has tried and failed at its built-in self-repair.
Common root causes:
- Failing physical media. Bad sectors in the MFT zone cause the read to return garbage. SMART data usually corroborates.
- Sudden power loss during a metadata-heavy operation. The transaction log normally rolls these back, but a corrupted
$LogFilewill defeat the rollback. - Driver- or filter-level corruption. Misbehaving disk encryption stacks, file system minifilters, or buggy storage drivers can write inconsistent records.
- Malicious overwrites. Wipers and some ransomware families deliberately scribble on
$MFTto make the volume harder to recover.
The forensically-sound response is:
- Stop writing to the volume immediately. Every further write reduces the chance of recovery.
- Image the disk with FTK Imager,
dd, orddrescueto a known-good destination. Verify the hash. - Work on the image, not the original. Try
testdisk,R-Studio, or a manual parse that findsFILErecords by signature scanning the volume directly — even if the on-disk pointer to$MFTis gone, the records themselves are usually still recognisable. - If the goal is to bring the volume back online rather than to recover data, only then run
chkdsk /fon the image.
chkdsk /b on a writable volume can clear bad-cluster markers, but it can also discard records it cannot understand. Run it on the original only after you have an image and have decided availability beats forensic fidelity.
How to read $MFT
You have three realistic options:
- MFTECmd (Eric Zimmerman) — a Windows CLI that produces CSV in the bodyfile-friendly layout most timeline tools expect. The de facto standard for incident responders.
omerbenamram/mft— a Rust crate and CLI. The same parser this site uses, useful when you want to script analysis or embed it in a larger pipeline.- This site's browser parser — drop
$MFTonto the homepage and it runs the same Rust parser, compiled to WebAssembly, entirely in your browser. Nothing is uploaded. Useful when you want a quick read without installing anything, or when policy forbids sending evidence to a cloud service.
If you need a comparison of the three with concrete pros and cons, see mft-parser-tools. For practical workflows that build on a parsed $MFT, see build-mft-timeline, deleted-files, and extracting-mft.
Frequently asked questions
What does MFT stand for?
MFT stands for Master File Table. It is also written $MFT on disk because, on NTFS, the dollar sign prefixes the names of metadata files.
What is the master file table used for?
It is the index NTFS uses to find every file and directory on a volume. Each entry stores the file's name, timestamps, security information, attributes, and the location of its data on disk.
What file attributes are stored in the master file table?
At minimum every record carries $STANDARD_INFORMATION (timestamps, DOS flags), $FILE_NAME (name and a second set of timestamps), and $DATA (the file's contents or a pointer to them). Records can also carry $ATTRIBUTE_LIST, $OBJECT_ID, $SECURITY_DESCRIPTOR, $INDEX_ROOT, $INDEX_ALLOCATION, $BITMAP, $REPARSE_POINT, $EA, and $LOGGED_UTILITY_STREAM depending on the file. The full reference is in the attributes table above.
How big is the master file table?
Each record is 1,024 bytes. The table reserves about 12.5% of the volume by default (the MFT zone) but only consumes the space it actually needs. A volume with a million files has roughly a 1 GB $MFT.
Is $MFT the same as $MFTMirr?
No. $MFTMirr is a partial backup of the first few records of $MFT, placed elsewhere on the disk so that NTFS can bootstrap recovery if the main table's header is corrupted.
How do I fix a corrupt master file table?
Image the disk first. Then either run chkdsk /f against the image (fast, may discard records), or use a recovery tool that can scan for FILE signatures and reassemble the table from raw clusters (slow, preserves more evidence). Never run chkdsk against the original volume before imaging.
Can I read $MFT on Linux or macOS?
Yes. $MFT is just a file. Any parser that accepts a raw $MFT dump works on any OS — omerbenamram/mft, analyzeMFT, this site's browser tool. You only need Windows to extract the file from a live mounted volume.