NTFS (New Technology File System)

NTFS was developed at Microsoft in the early 1990s as the default file system for Windows NT 3.1, released in 1993. The original team (Tom Miller, Gary Kimura, Brian Andrew, David Goebel) under Dave Cutler designed it to fix the limitations of FAT (4 GB max file, no permissions, no journaling) and to compete with the high-end file systems then available on Unix and OS/2. By Windows XP in 2001, NTFS reached version 3.1, which is essentially the same on-disk format used in Windows 11 and Windows Server 2025 today. The format has stayed remarkably stable for 25 years; major Windows versions have added features that build on NTFS rather than changing it.¹

The defining property of NTFS, the one that makes it different from every other consumer file system, is that everything on the volume is a file, and every file is described by a record in the Master File Table. Even the file system metadata is stored as files. This sounds like a circular definition until you see how it works in practice.

The Master File Table (MFT)

The Master File Table is the central data structure of an NTFS volume. It’s a database of records, one record per file or folder, with each record typically 1 KB in size. The MFT is itself a file (called $MFT), so the very first MFT record describes the MFT itself.²

Each MFT record contains:

• Standard information: timestamps (created, modified, accessed, MFT-changed), DOS file attributes (read-only, hidden, system, archive), and the security descriptor reference.
• File name: the file’s name in both Unicode (long name) and DOS 8.3 short name format if the volume has 8.3 generation enabled.
• Data attribute: the actual file content, OR (for files larger than ~700 bytes) a list of cluster runs pointing to where the data lives on disk.
• Other attributes: security descriptor, alternate data streams, reparse points, logged utility streams, and others depending on the file’s features.

Resident vs non-resident attributes

This is the part of NTFS that surprises people. Small files live entirely inside their MFT record, in what NTFS calls a “resident” data attribute. A file of 600 bytes might never occupy any clusters outside the MFT; the MFT record holds the file’s content directly. Larger files use “non-resident” attributes that point to cluster runs elsewhere on the volume. The threshold is approximately 700 bytes but varies based on what other attributes the file has.³

The recovery implication is significant: when you delete a small file, the MFT record is just marked unused, but the file’s content sits inside it untouched until something else reuses that record. This is one reason why deletion recovery on NTFS is often successful: the file isn’t anywhere else, but it’s still right there in the MFT.

The $LogFile journal

NTFS is a journaling file system. Every metadata change (creating a file, renaming, moving, changing permissions, expanding the MFT) is first written to a transaction log called $LogFile before being applied to the volume. After a crash or sudden power loss, NTFS replays the log on next mount to bring the volume back to a consistent state. Uncompleted transactions are rolled back; completed ones that hadn’t been flushed yet are reapplied.⁴

The $LogFile is also a recovery resource. Because it records the last several thousand metadata operations, a recovery tool can sometimes use it to reconstruct files that were deleted recently even when the MFT record has already been overwritten. Microsoft updated the $LogFile format in Windows 8 (version 2.0); volumes formatted on Windows 8+ can’t be fully written by Windows 7. Modern data recovery software handles both versions.

Special metadata files

NTFS keeps a dozen or so hidden metadata files at the start of every volume, each with a specific purpose. The names all start with $:

• $MFT: the Master File Table itself.
• $MFTMirr: a mirror copy of the first 4 MFT records (the most critical records that describe the MFT structure). Located in the middle of the volume so that a single physical disk failure can’t take both copies. This is the redundancy that makes most NTFS recovery possible.
• $LogFile: the transaction log described above.
• $Volume: volume-level metadata (label, version, dirty flag).
• $AttrDef: definitions of the attribute types NTFS uses.
• $Bitmap: bitmap of free vs allocated clusters across the entire volume.
• $Boot: the volume boot record (sector 0, plus a backup at the last sector).
• $BadClus: list of clusters marked as bad and remapped (NTFS’s bad sectors handling).
• $Secure: security descriptors for files, deduplicated to save space.
• $UpCase: Unicode uppercase translation table for case-insensitive comparisons.
• $Extend: directory holding additional metadata files (quotas, object IDs, reparse points, USN journal).

These files are normally invisible to user tools; they’re only accessible to the NTFS driver itself or to forensic tools that read the volume directly.

NTFS was designed to be a feature-rich file system at a time when most consumer file systems (FAT, FAT32) were stripped-down formats focused on portability. Many of its features are taken for granted today because they’re invisible to users: NTFS just works, and the features only become apparent when something goes wrong or when you compare it to other file systems.⁵

File-level permissions through ACLs

NTFS supports per-file and per-folder access control lists (ACLs) that grant specific users and groups specific kinds of access (read, write, execute, modify, take ownership, change permissions). This is the foundation of Windows multi-user security. ACLs travel with files when they’re moved within the same NTFS volume; copying or moving across volumes inherits the destination’s permissions instead. The security descriptors are stored centrally in $Secure and referenced by file MFT records, so a permission change on a thousand files doesn’t have to update a thousand records.

EFS encryption

The Encrypting File System (EFS) provides per-file encryption tied to user accounts. EFS uses a per-file symmetric key (FEK) that’s encrypted with the user’s certificate and stored as an attribute on the file. The encryption is transparent to the user: the file decrypts automatically when accessed by the authorized account. EFS is separate from BitLocker, which encrypts the whole volume. EFS protects against another user on the same machine reading your files; BitLocker protects against the entire drive being read by someone with physical access. Recovery of EFS-encrypted files without the original certificate is essentially impossible, even with raw disk access.

Transparent compression

NTFS supports per-file or per-folder compression using the LZNT1 algorithm. Files marked for compression are transparently compressed when written and decompressed when read. Compression ratios are typically 30 to 60% for documents and 10 to 20% for code; already-compressed files (JPEG, MP4, ZIP) gain almost nothing. The compression is handled by NTFS itself, not by the application, so any program can read a compressed file without knowing it was compressed. Compression and EFS encryption can’t be applied to the same file simultaneously.

Alternate Data Streams (ADS)

Every NTFS file can have multiple data streams. The default unnamed stream contains the file’s main content; named alternate streams can hold metadata, thumbnails, security zone information, or anything else. The syntax is filename.ext:streamname. macOS uses ADS to store extended attributes when files are saved to NTFS volumes (the famous :com.apple.metadata:_kMDItemUserTags). Windows uses ADS for the “Mark of the Web” zone identifier on downloaded files. The forensic implication: a file’s apparent size doesn’t always reflect its full content. Tools like streams.exe from Sysinternals enumerate all streams on a file.

Hard links, symbolic links, and junctions

NTFS supports three types of “this file is also at that other path” relationships:

• Hard links: multiple directory entries pointing to the same MFT record. Same data, two names. Both names are equal; deleting one doesn’t delete the data until the last hard link is gone.
• Junction points: directory-level redirections that work transparently to file system operations. Used by Windows for compatibility (e.g., C:\Documents and Settings as a junction to C:\Users).
• Symbolic links: added in Windows Vista. Like hard links but can cross volumes and point to non-existent targets, and can be relative or absolute. Require administrator privileges to create on default Windows configurations.

Sparse files

NTFS allows files to have “holes” of zero bytes that don’t actually occupy disk space. A sparse file might report a logical size of 100 GB while only consuming 10 GB on disk. Useful for VM disk images, database files, and any file format that pre-allocates space it might not use. Sparse files are common on Windows servers; they’re transparent to most applications because reads from holes return zeros and writes to holes allocate space as needed.

Other features worth knowing

• Disk quotas: per-user limits on disk space, useful in shared-machine and server scenarios.
• Reparse points: extensible mechanism that lets third-party file system drivers add custom behavior to specific files. Used by mount points, Distributed File System (DFS), and OneDrive’s offline files.
• Self-healing NTFS: added in Windows Vista. The file system can detect and repair minor corruption in the background without taking the volume offline. Reduces the need to run chkdsk for transient issues.
• USN journal (Update Sequence Number): a separate change journal that tracks file system changes for backup applications and search indexers.
• Volume Shadow Copy Service (VSS): a Windows feature that creates point-in-time snapshots of an NTFS volume. Essential for backup software that needs to capture a consistent state of an in-use volume.
• Transactional NTFS (TxF): added in Vista, deprecated since Windows 8. Allowed grouping multiple file operations into atomic transactions. Almost no software ever used it; Microsoft now recommends application-level transaction handling instead.

The three Windows file systems cover three different use cases, and choosing between them is one of the most common questions when formatting a new drive. The trade-offs come down to features, file/volume size limits, and cross-platform compatibility.⁶

Quick comparison

Property	NTFS	FAT32	exFAT
Year introduced	1993	1996	2006
Max file size	8 PB (practical)	4 GB	16 EB (theoretical)
Max volume size	256 TB (practical)	2 TB	128 PB
Journaling	Yes ($LogFile)	No	No
Permissions / ACLs	Yes	No	No
Encryption	EFS + BitLocker	No	BitLocker only
Compression	Yes	No	No
Hard links	Yes	No	No
Windows support	All modern (read+write)	All (read+write)	Win 7+ (read+write)
macOS support	Read-only (write needs Paragon/Tuxera)	Read+write	Read+write
Linux support	Read+write (NTFS3 driver)	Read+write	Read+write
Game consoles, TVs, cameras	Rarely	Universal	Some support
Best for	Internal Windows drives	Small drives for legacy devices	Cross-platform externals

When to use each

Use NTFS for any internal drive on a Windows system, any external drive that will be used primarily with Windows, and any drive that will hold files larger than 4 GB (modern video files routinely exceed this). NTFS is the default and the right choice unless you have a specific compatibility reason to choose otherwise.

Use FAT32 for small flash drives that need to work with old game consoles (PS3, original Xbox 360), car stereos, digital cameras with FAT firmware, and other legacy devices. FAT32 is the most universally compatible file system in existence; nearly every device made since 2000 can read it. The fatal limitation is the 4 GB per file maximum, which makes FAT32 unsuitable for modern video files or large archives.

Use exFAT for cross-platform external drives that need to handle files larger than 4 GB. exFAT is the standard for SDXC cards (which are exFAT-formatted by spec) and is widely supported across Windows, macOS, Linux (kernel 5.7+), and most modern devices. The trade-off is no journaling, which makes exFAT slightly more vulnerable to corruption from improper ejection. For external drives moved between Windows and macOS, exFAT is usually the right choice.⁷

NTFS doesn’t fail the way hardware fails. The drive itself works fine, but the structures NTFS uses to track files become inconsistent or damaged. The good news: NTFS was designed with redundancy specifically so that most corruption is repairable. The bad news: the repair tools (chkdsk especially) are aggressive and sometimes destroy more data than they save.⁸

• $Boot sector damage. The boot sector at sector 0 describes the volume layout (cluster size, MFT location, file system version). When it’s overwritten or corrupted, Windows shows the drive as RAW or prompts to format. NTFS keeps a backup boot sector at the last sector of the volume; tools like TestDisk can copy the backup over the primary to fix this.
• $MFT corruption. The most serious file system failure. The Master File Table itself becomes unreadable, leading to “Drive cannot be accessed” or “Corrupt master file table” errors. NTFS keeps the first 4 MFT records mirrored in $MFTMirr, so partial corruption is recoverable. If the MFT is destroyed beyond what $MFTMirr covers, recovery falls back to file carving.
• $LogFile corruption. Less common because $LogFile is rewritten constantly, but a bad sector inside $LogFile can prevent NTFS from mounting the volume cleanly. Marking $LogFile as “dirty” and letting Windows rebuild it on next mount usually resolves this.
• Cross-linked files. When two MFT records claim the same clusters, often as a result of firmware issues during writes or improper recovery from a previous problem. chkdsk’s typical fix is to truncate one of the files, which destroys data on whichever file got truncated. Recovery labs prefer to image the volume first and recover both files manually.
• Lost clusters. Clusters that aren’t marked free in $Bitmap but aren’t claimed by any file either. Usually a result of incomplete writes or interrupted operations. chkdsk recovers these as “Found.000\file0001.chk” files in the volume root, which is rarely useful but at least non-destructive.
• Bad sectors and $BadClus. Physical sectors that fail to read or write. NTFS’s $BadClus mechanism marks bad clusters as unusable and remaps file content elsewhere. This is graceful degradation, but as bad sectors accumulate, the volume becomes increasingly unreliable. SMART warnings are the upstream signal; check them before they cascade into file system corruption.
• Accidental quick format. A “Quick Format” of an NTFS volume creates a fresh, empty MFT but doesn’t overwrite the data clusters or the old MFT entries elsewhere on the volume. Files are recoverable using software that searches the volume for old MFT records (which still exist) or carves files by signature. A “Full Format” zeroes the data clusters and is much harder to recover from.
• Encryption ransomware. Modern ransomware encrypts file content while leaving the file system structures intact, so the MFT still shows the files but their content is unreadable without the decryption key. NTFS recovery tools can find the encrypted files but can’t decrypt them. Recovery depends on having pre-attack backups; paying the ransom is rarely effective.

Warning signs your NTFS volume is failing

NTFS gives several clear warnings before catastrophic failure. Watch for these in combination:

• Increasing chkdsk run times on routine boots, especially the “fixing record segment N” messages. NTFS is finding inconsistencies and repairing them, which usually points to drive-level issues underneath.
• Event Viewer NTFS errors (Event ID 55, 130, 137, others). The file system is reporting structural problems. Persistent errors indicate either bad HDD sectors or, less commonly, RAM issues affecting writes.
• Slowdowns when listing folder contents, particularly folders with many files. The MFT may be fragmented or the disk may be retrying reads on marginal sectors.
• Files that disappear and reappear between sessions. Often a sign of partial $LogFile replays where transactions are being undone after the fact.
• “File or directory is corrupted and unreadable” errors when accessing specific files. Usually MFT record damage on those specific files; recoverable.
• Drive showing as RAW in Disk Management or refusing to mount in Windows Explorer with “you need to format the disk before you can use it.” Critical: do not click “Format.” The data is still there.
• SMART warnings on the underlying disk. NTFS corruption is often the symptom of disk-level issues like bad sectors; address the disk before the file system becomes unrepairable.

NTFS has theoretical limits and practical limits, and they’re not the same. Microsoft has gradually relaxed the practical limits over the years as Windows itself caught up with the file system spec.⁹

Size limits

• Maximum volume size: 256 TB on Windows 10/11 with default 4 KB clusters; 8 PB theoretical with 2 MB clusters. Windows tools (Disk Management, format) won’t create volumes above 256 TB even on hardware that supports it.
• Maximum file size: 8 PB minus 2 MB on Windows 10 1709 and later; 256 TB on older Windows versions; 16 EB minus 1 KB theoretical maximum.
• Maximum number of files per volume: 4,294,967,295 (2^32 minus 1). The MFT can grow as files are added; once allocated, MFT space is rarely reclaimed.
• Maximum path length: 32,767 characters with the Unicode prefix; 260 characters in the legacy Win32 API. Most Windows applications still hit the 260-character limit.
• Maximum filename length: 255 characters. Names can include spaces, periods, and most Unicode characters; reserved names (CON, PRN, AUX, NUL, COM1-9, LPT1-9) are blocked.

Cross-platform compatibility

Windows. Universal support from Windows NT 3.1 (1993) through Windows 11 and Server 2025. Some advanced features (Transactional NTFS, latest $LogFile version, self-healing) are only available on newer Windows versions, but basic read/write works everywhere.

macOS. Read-only support natively since OS X. Write support requires third-party drivers like Paragon NTFS for Mac ($20-$40), Tuxera NTFS, or Mounty (a free FUSE-based driver with limitations). For external drives shared between Mac and Windows, exFAT is generally preferred over NTFS specifically because of this compatibility gap.

Linux. Two main drivers exist. The traditional NTFS-3G FUSE driver has been the standard for over a decade and supports nearly all NTFS features. Since Linux kernel 5.15 (released 2021), the in-kernel NTFS3 driver provides better performance and is now the recommended choice on modern distributions.¹⁰

Other systems. FreeBSD has read/write NTFS support via fusefs-ntfs. Game consoles, smart TVs, car stereos, and most embedded devices do not support NTFS; they expect FAT32 or exFAT. Some 2026-era smart TVs have added exFAT support; almost none have added NTFS.