NTFS ("New Technology
File System") is a proprietary file system
developed by Microsoft. Starting with
Windows NT 3.1, it is the
default file system of the
Windows NT family.
NTFS has several technical improvements over the file systems that it
File Allocation Table (FAT) and High Performance File
System (HPFS) – such as improved support for metadata and advanced
data structures to improve performance, reliability, and disk space
use. Additional extensions are a more elaborate security system based
on access control lists (ACLs) and file system journaling.
NTFS is supported in other desktop and server operating systems as
BSD have a free and open-source
NTFS driver, called
NTFS-3G, with both read and write functionality. macOS comes with
read-only support for NTFS; its disabled-by-default write support for
NTFS is unstable.
3.3 Hard links
3.4 Alternate data streams (ADS)
3.6 Sparse files
3.7 Volume Shadow Copy
3.12 Reparse points
4.1 Partition Boot Sector
4.4 Attribute lists, attributes, and streams
4.5 Resident vs. non-resident attributes
4.6 Opportunistic locks
6 See also
8 Further reading
In the mid-1980s,
IBM formed a joint project to create
the next generation of graphical operating system; the result was OS/2
and HPFS. Because
Microsoft disagreed with
IBM on many important
issues they eventually separated:
OS/2 remained an
IBM project and
Microsoft worked to develop
Windows NT and NTFS.
The HPFS file system for
OS/2 contained several important new
Microsoft created their new operating system, they
borrowed many of these concepts for NTFS.
NTFS developers include:
Tom Miller, Gary Kimura, Brian Andrew and David Goebel.
Probably as a result of this common ancestry, HPFS and
NTFS use the
same disk partition identification type code (07). Using the same
Partition ID Record Number is highly unusual, since there were dozens
of unused code numbers available, and other major file systems have
their own codes. For example, FAT has more than nine (one each for
FAT12, FAT16, FAT32, etc.). Algorithms identifying the file system in
a partition type 07 must perform additional checks to distinguish
between HPFS and NTFS.
Microsoft has released five versions of NTFS:
v1.0: Released with
Windows NT 3.1
Windows NT 3.1 in 1993. v1.0 is incompatible
with v1.1 and newer: Volumes written by
Windows NT 3.5x cannot be read
Windows NT 3.1
Windows NT 3.1 until an update (available on the NT 3.5x
installation media) is installed.
v1.1: Released with
Windows NT 3.51
Windows NT 3.51 in 1995. Supports compressed
files, named streams and access control lists
v1.2: Released with
Windows NT 4.0 in 1996. Supports security
descriptors. Commonly called
NTFS 4.0 after the OS release.
v3.0: Released with Windows 2000. Supports disk quotas, Encrypting
File System, sparse files, reparse points, update sequence number
(USN) journaling, the $Extend folder and its files. Reorganized
security descriptors so that multiple files using the same security
setting can share the same descriptor. Commonly called
after the OS release.
v3.1: Released with
Windows XP in October 2001 (and subsequently used
Windows Vista and Windows 7). Expanded the Master
(MFT) entries with redundant MFT record number (useful for recovering
damaged MFT files). Commonly called
NTFS 5.1 after the OS release
The NTFS.sys version number (e.g. v5.0 in Windows 2000) is based on
the operating system version; it should not be confused with the NTFS
version number (v3.1 since Windows XP).
Although subsequent versions of Windows added new file system-related
features, they did not change
NTFS itself. For example, Windows Vista
NTFS symbolic links, Transactional NTFS, partition
shrinking, and self-healing.
NTFS symbolic links are a new feature
in the file system; all the others are new operating system features
that make use of
NTFS features already in place.
NTFS v3.0 includes several new features over its predecessors: sparse
file support, disk use quotas, reparse points, distributed link
tracking, and file-level encryption called the Encrypting
NTFS is optimized for 4 KB clusters, but supports a maximum
cluster size of 64 KB. The maximum
NTFS volume size that the
specification can support is 264 − 1 clusters, but not all
implementations achieve this theoretical maximum, as discussed below.
NTFS volume size implemented in
Windows XP Professional is
232 − 1 clusters, partly due to partition table limitations. For
example, using 64 KB clusters, the maximum size
Windows XP NTFS
volume is 256 TB minus 64 KB. Using the default cluster size
of 4 KB, the maximum
NTFS volume size is 16 TB minus
4 KB. Both of these are vastly higher than the 128 GB limit
Windows XP SP1. Because partition tables on master boot record
(MBR) disks support only partition sizes up to 2 TB, multiple
GUID Partition Table
GUID Partition Table (GPT or "dynamic") volumes must be combined to
create a single
NTFS volume larger than 2 TB. Booting from a GPT
volume to a Windows environment in a
Microsoft supported way requires
a system with
Unified Extensible Firmware Interface
Unified Extensible Firmware Interface (UEFI) and 64-bit
NTFS maximum theoretical limit on the size of individual files is
16 EiB (16 × 10246 or 264 bytes) minus 1 KB, which totals
to 18,446,744,073,709,550,592 bytes. With
Windows 8 and Windows Server
2012, the maximum implemented file size is 256 TB minus
64 KB or 281,474,976,645,120 bytes.
NTFS is a journaling file system and uses the
NTFS Log ($LogFile) to
record metadata changes to the volume. It is a feature that FAT does
not provide and critical for
NTFS to ensure that its complex internal
data structures will remain consistent in case of system crashes or
data moves performed by the defragmentation API, and allow easy
rollback of uncommitted changes to these critical data structures when
the volume is remounted. Notably affected structures are the volume
allocation bitmap, modifications to MFT records such as moves of some
variable-length attributes stored in MFT records and attribute lists,
and indices for directories and security descriptors.
USN Journal (Update Sequence Number Journal) is a system
management feature that records (in $Extend$UsnJrnl) changes to files,
streams and directories on the volume, as well as their various
attributes and security settings. The journal is made available for
applications to track changes to the volume. This journal can be
enabled or disabled on non-system volumes.
The hard link feature allows different file names to directly refer to
the same file contents. Hard links are similar to directory junctions,
but refer to files instead. Hard links may link only to files in the
same volume, because each volume has its own MFT. Hard links have
their own file metadata, so a change in file size or attributes under
one hard link may not update the others until they are opened.
Hard links were originally included to support the
POSIX subsystem in
Windows uses hard links to support short (8.3) filenames in NTFS.
Operating system support is needed because there are legacy
applications that can work only with 8.3 filenames. In this case, an
additional filename record and directory entry is added, but both 8.3
and long file name are linked and updated together, unlike a regular
NTFS file system has a limit of 1024 hard links on a file.
Alternate data streams (ADS)
Main article: Fork (file system)
Alternate data streams allow more than one data stream to be
associated with a filename (a fork), using the format
"filename:streamname" (e.g., "text.txt:extrastream").
NTFS Streams were introduced in
Windows NT 3.1, to enable Services for
Macintosh (SFM) to store resource forks. Although current versions of
Windows Server no longer include SFM, third-party Apple Filing
Protocol (AFP) products (such as GroupLogic's ExtremeZ-IP) still use
this feature of the file system. Very small ADS (named
"Zone.Identifier") are added by
Internet Explorer and recently by
other browsers to mark files downloaded from external sites as
possibly unsafe to run; the local shell would then require user
confirmation before opening them. When the user indicates that
they no longer want this confirmation dialog, this ADS is deleted.
Alternate streams are not listed in Windows Explorer, and their size
is not included in the file's size. When the file is copied or moved
to another file system without ADS support the user is warned that
alternate data streams cannot be preserved. No such warning is
typically provided if the file is attached to an e-mail, or uploaded
to a website. Thus, using alternate streams for critical data may
Microsoft provides a tool called Streams to view
streams on a selected volume. Starting with
Windows PowerShell 3.0, it
is possible to manage ADS natively with six cmdlets: Add-Content,
Clear-Content, Get-Content, Get-Item, Remove-Item, Set-Content.
Malware has used alternate data streams to hide code. As a result,
malware scanners and other special tools now check for alternate data
NTFS can compress files using LZNT1 algorithm (a variant of LZ77)
Files are compressed in 16 cluster chunks. With 4 KB clusters,
files are compressed in 64 KB chunks. The compression algorithms
NTFS are designed to support cluster sizes of up to 4 KB. When
the cluster size is greater than 4 KB on an
NTFS volume, NTFS
compression is not available. If the compression reduces
64 KB of data to 60 KB or less,
NTFS treats the unneeded
4 KB pages like empty sparse file clusters—they are not
written. This allows for reasonable random-access times as the OS just
has to follow the chain of fragments. However, large compressible
files become highly fragmented since every chunk smaller than
64 KB becomes a fragment. According to research by
NTFS Development team, 50–60 GB is a reasonable
maximum size for a compressed file on an
NTFS volume with a 4 KB
(default) cluster (block) size. This reasonable maximum size decreases
sharply for volumes with smaller cluster sizes. Single-user
systems with limited hard disk space can benefit from
for small files, from 4 KB to 64 KB or more, depending on
compressibility. Files smaller than approximately 900 bytes are
stored within the directory entry of the MFT.
Flash memory, such as
SSD drives do not have the head movement delays
of hard disk drives, so fragmentation has only a smaller penalty.
Users of fast multi-core processors will find improvements in
application speed by compressing their applications and data as well
as a reduction in space used. Note that SSDs with Sandforce
controllers already compress data. However, since less data is
transferred, there is a reduction in I/Os.
Compression works best with files that have repetitive content, are
seldom written, are usually accessed sequentially, and are not
themselves compressed. Log files are an ideal example.
If system files that are needed at boot time (such as drivers, NTLDR,
winload.exe, or BOOTMGR) are compressed, the system may fail to boot
correctly, because decompression filters are not yet loaded. Later
editions of Windows[which?] do not allow important system files to be
Files may be compressed or decompressed individually (via changing the
advanced attributes) for a drive, directory, or directory tree,
becoming a default for the files inside.
Although read–write access to compressed files is mostly
Microsoft recommends avoiding compression on server
systems and/or network shares holding roaming profiles, because it
puts a considerable load on the processor.
A sparse file: Empty bytes don't need to be saved, thus they can be
represented by metadata.
Sparse files are files interspersed with empty segments for which no
actual storage space is used. To the applications, the file looks like
an ordinary file with empty regions seen as regions filled with
Database applications, for instance, may use sparse files. As with
compressed files, the actual sizes of sparse files are not taken into
account when determining quota limits.
Volume Shadow Copy
Shadow Copy Service (VSS) keeps historical versions of
files and folders on
NTFS volumes by copying old, newly overwritten
data to shadow copy via copy-on-write technique. The user may later
request an earlier version to be recovered. This also allows data
backup programs to archive files currently in use by the file system.
On heavily loaded systems,
Microsoft recommends setting up a shadow
copy volume on a separate disk.
Windows Vista also introduced persistent shadow copies for use with
System Restore and
Previous Versions features. Persistent shadow
copies, however, are deleted when an older operating system mounts
NTFS volume. This happens because the older operating system does
not understand the newer format of persistent shadow copies.
As of Windows Vista, applications can use
Transactional NTFS (TxF) to
group multiple changes to files together into a single transaction.
The transaction will guarantee that either all of the changes happen,
or none of them do, and that no application outside the transaction
will see the changes until they are committed.
It uses similar techniques as those used for Volume Shadow Copies
(i.e. copy-on-write) to ensure that overwritten data can be safely
rolled back, and a CLFS log to mark the transactions that have still
not been committed, or those that have been committed but still not
fully applied (in case of system crash during a commit by one of the
Transactional NTFS does not restrict transactions to just the local
NTFS volume, but also includes other transactional data or operations
in other locations such as data stored in separate volumes, the local
registry, or SQL databases, or the current states of system services
or remote services. These transactions are coordinated network-wide
with all participants using a specific service, the DTC, to ensure
that all participants will receive same commit state, and to transport
the changes that have been validated by any participant (so that the
others can invalidate their local caches for old data or rollback
their ongoing uncommitted changes).
Transactional NTFS allows, for
example, the creation of network-wide consistent distributed file
systems, including with their local live or offline caches.
Microsoft now advises against using TxF: "
recommends developers utilize alternative means..." since "TxF may not
be available in future versions of
In NTFS, each file or folder is assigned a security descriptor that
defines its owner and contains two access control lists (ACLs). The
first ACL, called discretionary access control list (DACL), defines
exactly what type of interactions (e.g. reading, writing, executing or
deleting) are allowed or forbidden by which user or groups of users.
For example, files in the C:Program Files folder may be read and
executed by all users but modified only by a user holding
Windows Vista adds mandatory access
control info to DACLs. DACLs are the primary focus of User Account
Windows Vista and later.
The second ACL, called system access control list (SACL), defines
which interactions with the file or folder are to be audited and
whether they should be logged when the activity is successful, failed
or both. For example, auditing can be enabled on sensitive files of a
company, so that its managers get to know when someone tries to delete
them or make a copy of them, and whether he or she succeeds.
Main article: Encrypting
File System (EFS) provides strong and user-transparent
encryption of any file or folder on an
NTFS volume. EFS works in
conjunction with the EFS service, Microsoft's CryptoAPI and the EFS
File System Run-Time Library (FSRTL). EFS works by encrypting a file
with a bulk symmetric key (also known as the
File Encryption Key, or
FEK), which is used because it takes a relatively small amount of time
to encrypt and decrypt large amounts of data than if an asymmetric key
cipher is used. The symmetric key that is used to encrypt the file is
then encrypted with a public key that is associated with the user who
encrypted the file, and this encrypted data is stored in an alternate
data stream of the encrypted file. To decrypt the file, the file
system uses the private key of the user to decrypt the symmetric key
that is stored in the file header. It then uses the symmetric key to
decrypt the file. Because this is done at the file system level, it is
transparent to the user. Also, in case of a user losing access to
their key, support for additional decryption keys has been built into
the EFS system, so that a recovery agent can still access the files if
needed. NTFS-provided encryption and NTFS-provided compression are
mutually exclusive; however,
NTFS can be used for one and a
third-party tool for the other.
The support of EFS is not available in Basic, Home, and MediaCenter
versions of Windows, and must be activated after installation of
Professional, Ultimate, and Server versions of Windows or by using
enterprise deployment tools within Windows domains.
Disk quotas were introduced in
NTFS v3. They allow the administrator
of a computer that runs a version of Windows that supports
NTFS to set
a threshold of disk space that users may use. It also allows
administrators to keep track of how much disk space each user is
using. An administrator may specify a certain level of disk space that
a user may use before they receive a warning, and then deny access to
the user once they hit their upper limit of space. Disk quotas do not
take into account NTFS's transparent file-compression, should this be
enabled. Applications that query the amount of free space will also
see the amount of free space left to the user who has a quota applied
NTFS reparse point
NTFS reparse points, introduced in
NTFS v3, are used by associating a
reparse tag in the user space attribute of a file or directory.
Microsoft includes several default tags including
NTFS symbolic links,
directory junction points and volume mount points. When the object
Windows NT line executive) parses a file system name
lookup and encounters a reparse attribute, it will reparse the name
lookup, passing the user controlled reparse data to every file system
filter driver that is loaded into Windows. Each filter driver examines
the reparse data to see whether it is associated with that reparse
point, and if that filter driver determines a match, then it
intercepts the file system call and executes its special
Microsoft added the built-in ability to
shrink or expand a partition. However, this ability does not relocate
page file fragments or files that have been marked as unmovable, so
shrinking a volume will often require relocating or disabling any page
file, the index of Windows Search, and any
Shadow Copy used by System
Restore. Various third-party tools are capable of resizing NTFS
NTFS file system permissions on a
Windows Vista system
NTFS uses B-trees to index file system data. Although
complex to implement, this allows faster file look up times in most
cases. A file system journal is used to guarantee the integrity of the
file system metadata but not individual files' content. Systems using
NTFS are known to have improved reliability compared to FAT file
NTFS allows any sequence of 16-bit values for name encoding (file
names, stream names, index names, etc.) except 0x0000. This means
UTF-16 code units are supported, but the file system does not check
whether a sequence is valid
UTF-16 (it allows any sequence of short
values, not restricted to those in the Unicode standard).
are limited to 255
UTF-16 code units. Certain names are reserved in
the volume root directory and cannot be used for files. These are
$MFT, $MFTMirr, $LogFile, $Volume, $AttrDef, . (dot), $Bitmap, $Boot,
$BadClus, $Secure, $UpCase, and $Extend. (dot) and $Extend are both
directories; the others are files. The NT kernel limits full paths to
UTF-16 code units. There are some additional restrictions on
code points and file names.
Partition Boot Sector
NTFS boot sector contents (All values except strings are
stored in little endian order.)
Causes execution to continue after the data structures in this boot
Word "NTFS" followed by four trailing spaces (0x20)
This is the magic cookie that indicates this is an
NTFS file system.
Bytes per sector
The number of bytes in a disk sector.
Sectors Per Cluster
The number of sectors in a cluster
Reserved Sectors, unused
How much space is reserved by the OS at the start of disk. This is
This field is always 0
Unused by NTFS
This field is always 0
The type of drive. 0xF8 is used to denote a hard drive (in contrast to
the several sizes of floppy).
This field is always 0
Sectors Per Track
The number of disk sectors in a drive track.
Number Of Heads
The number of heads on the drive.
The number of sectors preceding the partition.
Not used by NTFS
Not used by NTFS
The partition size in sectors.
$MFT cluster number
The cluster that contains the Master
$MFTMirr cluster number
The cluster that contains a backup of the Master
File Record Segment
The number of clusters in a
File Record Segment. A negative number
denotes that the size is 2 to the power of the absolute value. (0xF6 =
-10 → 2^10 = 1024).
This field is not used by NTFS
Clusters Per Index Buffer
The number of clusters in an Index Buffer. This uses the same
algorithm for negative numbers as the "Clusters Per
This field is not used by NTFS
Volume Serial Number
A unique random number assigned to this partition, to keep things
Supposedly a checksum.
The code that loads the rest of the operating system. This is pointed
to by the first 3 bytes of this sector.
This flag indicates that this is a valid boot sector.
This boot partition format is roughly based upon the earlier FAT
filesystem, but the fields are in different locations. Some of these
fields, especially the "sectors per track," "number of heads" and
"hidden sectors" fields may contain dummy values on drives where they
either don't make sense or aren't determinable.
The OS first looks at the 8 bytes at 0x30 to find the cluster number
of the $MFT, then multiplies that number by the number of sectors per
cluster (1 byte found at 0x0D). This value is the sector offset (LBA)
to the $MFT, which is described below.
In NTFS, all file, directory and metafile data—file name, creation
date, access permissions (by the use of access control lists), and
size—are stored as metadata in the Master
File Table (MFT). This
abstract approach allowed easy addition of file system features during
Windows NT's development—an example is the addition of fields for
indexing used by the
Active Directory software. This also enables fast
file search software such as Everything to locate named local files
and folders included in the MFT very quickly, without requiring any
The MFT structure supports algorithms which minimize disk
fragmentation. A directory entry consists of a filename and a
"file ID", which is the record number representing the file in the
File Table. The file ID also contains a reuse count to detect
stale references. While this strongly resembles the W_FID of Files-11,
NTFS structures radically differ.
Two copies of the MFT are stored in case of corruption. If the first
record is corrupted,
NTFS reads the second record to find the MFT
mirror file. Locations for both files are stored in the boot
NTFS contains several files that define and organize the file system.
In all respects, most of these files are structured like any other
user file ($Volume being the most peculiar), but are not of direct
interest to file system clients. These metafiles define files, back up
critical file system data, buffer file system changes, manage free
space allocation, satisfy
BIOS expectations, track bad allocation
units, and store security and disk space usage information. All
content is in an unnamed data stream, unless otherwise indicated.
Describes all files on the volume, including file names, timestamps,
stream names, and lists of cluster numbers where data streams reside,
indexes, security identifiers, and file attributes like "read only",
"compressed", "encrypted", etc.
Duplicate of the first vital entries of $MFT, usually 4 entries (4
Contains transaction log of file system metadata changes.
Contains information about the volume, namely the volume object
identifier, volume label, file system version, and volume flags
(mounted, chkdsk requested, requested $Log
File resize, mounted on NT
4, volume serial number updating, structure upgrade request). This
data is not stored in a data stream, but in special MFT attributes: If
present, a volume object ID is stored in an $OBJECT_ID record; the
volume label is stored in a $VOLUME_NAME record, and the remaining
volume data is in a $VOLUME_INFORMATION record. Note: volume serial
number is stored in file $Boot (below).
A table of MFT attributes that associates numeric identifiers with
Root directory. Directory data is stored in $INDEX_ROOT and
$INDEX_ALLOCATION attributes both named $I30.
An array of bit entries: each bit indicates whether its corresponding
cluster is used (allocated) or free (available for allocation).
Volume boot record. This file is always located at the first clusters
on the volume. It contains bootstrap code (see NTLDR/BOOTMGR) and a
BIOS parameter block including a volume serial number and cluster
numbers of $MFT and $MFTMirr.
A file that contains all the clusters marked as having bad sectors.
This file simplifies cluster management by the chkdsk utility, both as
a place to put newly discovered bad sectors, and for identifying
unreferenced clusters. This file contains two data streams, even on
volumes with no bad sectors: an unnamed stream contains bad
sectors—it is zero length for perfect volumes; the second stream is
named $Bad and contains all clusters on the volume not in the first
Access control list database that reduces overhead having many
identical ACLs stored with each file, by uniquely storing these ACLs
only in this database (contains two indices: $SII
(Standard_Information ID) and $SDH (
Security Descriptor Hash), which
index the stream named $SDS containing actual ACL table).
A table of unicode uppercase characters for ensuring
Win32 and DOS namespaces.
A file system directory containing various optional extensions, such
as $Quota, $ObjId, $Reparse or $UsnJrnl.
Reserved for $MFT extension entries. Extension entries are additional
MFT records that contain additional attributes that do not fit in the
primary record. This could occur if the file is sufficiently
fragmented, has many streams, long filenames, complex security, or
other rare situations.
Holds disk quota information. Contains two index roots, named $O and
Holds link tracking information. Contains an index root and allocation
Holds reparse point data (such as symbolic links). Contains an index
root and allocation named $R.
Beginning of regular file entries.
These metafiles are treated specially by Windows, handled directly by
the NTFS.SYS driver and are difficult to directly view: special
purpose-built tools are needed. As of Windows 7, the
completely prohibits user access, resulting in a
BSoD whenever an
attempt to execute a metadata file is made. One such tool is the
File Sector Information Utility") that is freely
distributed as part of the
Microsoft "OEM Support Tools". For example,
to obtain information on the "$MFT"-Master
File Table Segment the
following command is used: nfi
.exe c:$MFT Another way to bypass
the restriction is to use 7-zip's file manager and go to the low-level
NTFS path \.X: (where X: resembles any drive/partition). Here, 3 new
folders will appear: $EXTEND, [DELETED] (a pseudo-folder that 7-zip
uses to attach files deleted from the file system to view), and
[SYSTEM] (another pseudo-folder that contains all the
files). This trick can be used from removable devices (
drives, external hard drives, SD Cards, etc.) inside Windows, but
doing this on the active partition requires offline access (namely
Attribute lists, attributes, and streams
For each file (or directory) described in the MFT record, there is a
linear repository of stream descriptors (also named attributes),
packed together in one or more MFT records (containing the so-called
attributes list), with extra padding to fill the fixed 1 KB size
of every MFT record, and that fully describes the effective streams
associated with that file.
Each attribute has an attribute type (a fixed-size integer mapping to
an attribute definition in file $AttrDef), an optional attribute name
(for example, used as the name for an alternate data stream), and a
value, represented in a sequence of bytes. For NTFS, the standard data
of files, the alternate data streams, or the index data for
directories are stored as attributes.
According to $AttrDef, some attributes can be either resident or
non-resident. The $DATA attribute, which contains file data, is such
an example. When the attribute is resident (which is represented by a
flag), its value is stored directly in the MFT record. Otherwise,
clusters are allocated for the data, and the cluster location
information is stored as data runs in the attribute.
For each file in the MFT, the attributes identified by attribute type,
attribute name must be unique. Additionally,
NTFS has some ordering
constraints for these attributes.
There is a predefined null attribute type, used to indicate the end of
the list of attributes in one MFT record. It must be present as the
last attribute in the record (all other storage space available after
it will be ignored and just consists of padding bytes to match the
record size in the MFT).
Some attribute types are required and must be present in each MFT
record, except unused records that are just indicated by null
This is the case for $STANDARD_INFORMATION attribute that is stored as
a fixed-size record and containing the timestamps and other basic
single-bit attributes (compatible with those managed by FAT in DOS or
Some attribute types cannot have a name and must remain anonymous.
This is the case for the standard attributes, or for the preferred
NTFS "filename" attribute type, or the "short filename" attribute
type, when it is also present (for compatibility with DOS-like
applications, see below). It is also possible for a file to contain
only a short filename, in which case it will be the preferred one, as
listed in the Windows Explorer.
The filename attributes stored in the attribute list do not make the
file immediately accessible through the hierarchical file system. In
fact, all the filenames must be indexed separately in at least one
separate directory on the same volume, with its own MFT record and its
own security descriptors and attributes, that will reference the MFT
record number for that file. This allows the same file or directory to
be "hardlinked" several times from several containers on the same
volume, possibly with distinct filenames.
The default data stream of a regular file is a stream of type $DATA
but with an anonymous name, and the ADSs are similar but must be
On the opposite, the default data stream of directories has a distinct
type, but are not anonymous: they have an attribute name ("$I30" in
NTFS 3+) that reflects its indexing format.
All attributes of a given file may be displayed by using the nfi.exe
File Sector Information Utility") that is freely distributed as
part of the
Microsoft "OEM Support Tools".
Windows system calls may handle alternate data streams. Depending
on the operating system, utility and remote file system, a file
transfer might silently strip data streams. A safe way of copying
or moving files is to use the BackupRead and BackupWrite system calls,
which allow programs to enumerate streams, to verify whether each
stream should be written to the destination volume and to knowingly
skip unwanted streams.
Resident vs. non-resident attributes
To optimize the storage and reduce the I/O overhead for the very
common case of attributes with very small associated value, NTFS
prefers to place the value within the attribute itself (if the size of
the attribute does not then exceed the maximum size of an MFT record),
instead of using the MFT record space to list clusters containing the
data; in that case, the attribute will not store the data directly but
will just store an allocation map (in the form of data runs) pointing
to the actual data stored elsewhere on the volume. When the value
can be accessed directly from within the attribute, it is called
"resident data" (by computer forensics workers). The amount of data
that fits is highly dependent on the file's characteristics, but 700
to 800 bytes is common in single-stream files with non-lengthy
filenames and no ACLs.
Some attributes (such as the preferred filename, the basic file
attributes) cannot be made non-resident. For non-resident attributes,
their allocation map must fit within MFT records.
Encrypted-by-NTFS, sparse data streams, or compressed data streams
cannot be made resident.
The format of the allocation map for non-resident attributes depends
on its capability of supporting sparse data storage. In the current
implementation of NTFS, once a non-resident data stream has been
marked and converted as sparse, it cannot be changed back to
non-sparse data, so it cannot become resident again, unless this data
is fully truncated, discarding the sparse allocation map completely.
When a non-resident attribute is so fragmented, that its effective
allocation map cannot fit entirely within one MFT record,
the attribute in multiple records. The first one among them is called
the base record, while the others are called extension records. NTFS
creates a special attribute $ATTRIBUTE_LIST to store information
mapping different parts of the long attribute to the MFT records,
which means the allocation map may be split into multiple records. The
$ATTRIBUTE_LIST itself can also be non-resident, but its own
allocation map must fit within one MFT record.
When there are too many attributes for a file (including ADS's,
extended attributes, or security descriptors), so that they cannot fit
all within the MFT record, extension records may also be used to store
the other attributes, using the same format as the one used in the
base MFT record, but without the space constraints of one MFT record.
The allocation map is stored in a form of data runs with compressed
encoding. Each data run represents a contiguous group of clusters that
store the attribute value. For files on a multi-GB volume, each entry
can be encoded as 5 to 7 bytes, which means a 1 KB MFT record can
store about 100 such data runs. However, as the $ATTRIBUTE_LIST also
has a size limit, it is dangerous to have more than 1 million
fragments of a single file on an
NTFS volume, which also implies that
it is in general not a good idea to use
NTFS compression on a file
larger than 10 GB.
NTFS file system driver will sometimes attempt to relocate the
data of some of the attributes that can be made non-resident into the
clusters, and will also attempt to relocate the data stored in
clusters back to the attribute inside the MFT record, based on
priority and preferred ordering rules, and size constraints.
Since resident files do not directly occupy clusters ("allocation
units"), it is possible for an
NTFS volume to contain more files on a
volume than there are clusters. For example, a 74.5 GB partition NTFS
formats with 19,543,064 clusters of 4 KB. Subtracting system files (a
64 MB log file, a 2,442,888-byte Bitmap file, and about 25 clusters of
fixed overhead) leaves 19,526,158 clusters free for files and indices.
Since there are four MFT records per cluster, this volume
theoretically could hold almost 4 × 19,526,158= 78,104,632 resident
Opportunistic file locks (oplocks) allow clients to alter their
buffering strategy for a given file or stream in order to increase
performance and reduce network use. Oplocks apply to the given
open stream of a file and do not affect oplocks on a different stream.
Oplocks can be used to transparently access files in the background. A
network client may avoid writing information into a file on a remote
server if no other process is accessing the data, or it may buffer
read-ahead data if no other process is writing data.
Windows supports four different types of oplocks:
Level 2 (or shared) oplock: multiple readers, no writers (i.e. read
Level 1 (or exclusive) oplock: exclusive access with arbitrary
buffering (i.e. read and write caching).
Batch oplock (also exclusive): a stream is opened on the server, but
closed on the client machine (i.e. read, write and handle caching).
Filter oplock (also exclusive): applications and file system filters
can "back out" when others try to access the same stream (i.e. read
and write caching) (since Windows 2000)
Opportunistic locks have been enhanced in
Windows 7 and Windows Server
2008 R2 with per-client oplock keys.
Windows NT and its descendants keep internal timestamps as
make the appropriate conversions for display purposes; all NTFS
timestamps are in UTC.
For historical reasons, the versions of Windows that do not support
NTFS all keep time internally as local zone time, and therefore so do
all file systems – other than
NTFS – that are supported by current
versions of Windows. This means that when files are copied or moved
NTFS and non-
NTFS partitions, the OS needs to convert
timestamps on the fly. But if some files are moved when daylight
saving time (DST) is in effect, and other files are moved when
standard time is in effect, there can be some ambiguities in the
conversions. As a result, especially shortly after one of the days on
which local zone time changes, users may observe that some files have
timestamps that are incorrect by one hour. Due to the differences in
implementation of DST in different jurisdictions, this can result in a
potential timestamp error of up to 4 hours in any given
While the different
NTFS versions are for the most part fully forward-
and backward-compatible, there are technical considerations for
NTFS volumes in older versions of
This affects dual-booting, and external portable hard drives. For
example, attempting to use an
NTFS partition with "Previous Versions"
(a.k.a. Volume Shadow Copy) on an operating system that does not
support it will result in the contents of those previous versions
being lost. A Windows command-line utility called convert
convert supporting file systems to NTFS, including HPFS (only on
Windows NT 3.1, 3.5, and 3.51),
Windows 2000 and
Mac OS X 10.3
Mac OS X 10.3 and later include read-only support for NTFS-formatted
partitions. The GPL-licensed
NTFS-3G also works on Mac OS X through
FUSE and allows reading and writing to
NTFS partitions. A performance
enhanced commercial version, called
NTFS for Mac, is also
available from the
Paragon Software Group
Paragon Software Group sells a
read-write driver named
NTFS for Mac OS X, which is also included
on some models of Seagate hard drives. Native
NTFS write support
has been discovered in Mac OS X 10.6 and later, but is not activated
by default, although workarounds do exist to enable the functionality.
However, user reports indicate the functionality is unstable and tends
to cause "kernel panics", probably the reason why write support has
not been enabled or advertised.
Linux kernel versions 2.2.0 and later include the ability to read NTFS
partitions; kernel versions 2.6.0 and later contain a driver written
by Anton Altaparmakov (University of Cambridge) and Richard Russon
which supports file read, overwrite and resize. Three userspace
NTFS-3G and Captive NTFS, a 'wrapping' driver that
uses Windows' own driver, ntfs.sys) exist for
NTFS support. They are
built on the
Filesystem in Userspace
Filesystem in Userspace (FUSE), a
Linux kernel module
tasked with bridging userspace and kernel code to save and retrieve
data. All three are licensed under the terms of the GNU General Public
License (GPL). Due to the complexity of internal
NTFS structures, both
the built-in 2.6.14 kernel driver and the FUSE drivers disallow
changes to the volume that are considered unsafe, to avoid
corruption. Two proprietary solutions also exist:
NTFS — A high-performance read/write commercial kernel
driver, mainly targeted for embedded devices from Tuxera, which also
Linux — A commercial driver with full read/write support
from Paragon Software Group.
eComStation, and Free
BSD offer read-only
NTFS support (there is a beta
NTFS driver that allows write/delete for eComStation, but is generally
considered unsafe). A free third-party tool for BeOS, which was based
on NTFS-3G, allows full
NTFS read and write.
NTFS-3G, a free implementation of NTFS, while initially developed for
Linux, also works on macOS, FreeBSD, NetBSD, OpenBSD (where
NTFS-3G is available from ports), Solaris,
QNX and Haiku, through
There is a free for personal use read/write driver for
Ahead Software developed a "NTFSREAD" driver
(version 1.200) for
DR-DOS 7.0x between 2002 and 2004. It was part of
Nero Burning ROM
Nero Burning ROM software.
BSD offer native read-only
NTFS support by default on i386 and
amd64 platforms as of version 4.9 released 1 May 2011.
Comparison of file systems
^ a b c "1.1 Glossary". [MS-EFSR]: Encrypting
File System Remote
(EFSRPC) Protocol. Microsoft. 14 November 2013.
NTFS Works". TechNet. Microsoft. Retrieved 2 December
^ a b c d e f g "How
Windows Server 2003
Windows Server 2003 Technical
Reference. 2003-03-28. Retrieved 2011-09-12.
^ a b "6 Appendix A: Product Behavior". [MS-FSA]:
Algorithms. Microsoft. 14 November 2013. Retrieved 2012-09-21.
^ a b Russon, Richard; Fledel, Yuval. "
NTFS Documentation" (PDF).
^ Rick Vanover. "Windows Server 8 data deduplication". Retrieved
^ a b Custer, Helen (1994). Inside the
Microsoft Press. ISBN 978-1-55615-660-1.
^ Kozierok, Charles M. (April 17, 2001). "Overview and History of
^ Custer, Helen (1994). Inside the
File System. Microsoft
Press. p. vii. ISBN 978-1-55615-660-1.
Windows NT After a Boot Failure on an
Microsoft. November 1, 2006.
^ a b c Russinovich, Mark. "Inside Win2K NTFS, Part 1". MSDN.
Microsoft. Retrieved 2008-04-18.
^ "Inside Win2K NTFS, Part 1". Microsoft. January 26, 2011.
^ "New Capabilities and Features of the
Microsoft. 1 December 2007.
^ Loveall, John (2006). "Storage improvements in
Windows Vista and
Windows Server 2008" (PowerPoint). Microsoft. pp. 14–20.
File System Algorithms. Appendix A: Product Behavior".
Microsoft. Retrieved 2012-01-10.
^ "Change Journals (Windows)". MSDN. Retrieved 2010-04-16.
^ "Creating, Modifying, and Deleting a Change Journal (Windows)".
MSDN. Retrieved 2010-04-16.
^ "Hard Links and Junctions". MSDN. Microsoft. 12 October 2013.
Retrieved 21 October 2013.
^ "Chapter 29 –
POSIX Compatibility". MS
Windows NT Workstation 4.0
Resource Guide. Microsoft. 1995. Retrieved 21 October 2013.
MSDN – CreateHardLink function". Retrieved 14 January 2016.
^ Russinovich, Mark E.; Solomon, David A.; Ionescu, Alex (2009). "File
Systems". Windows Internals (5th ed.).
Microsoft Press. p. 921.
ISBN 978-0-7356-2530-3. One component in Windows that uses
multiple data streams is the Attachment Execution Service[...]
depending on which zone the file was downloaded from [...] Windows
Explorer might warn the user
^ Sysinternals Streams v1.56
^ "FileSystem Provider". Microsoft. 9 August 2012. Archived from the
original on 23 January 2015. Retrieved 23 January 2015.
Malware utilising Alternate Data Streams? Archived 2008-07-23 at the
Wayback Machine., AusCERT Web Log, 21 August 2007
File Compression and Decompression".
MSDN Platform SDK: File
Systems. Retrieved 2005-08-18.
^ "The Default Cluster Size for the
NTFS and FAT
Microsoft. January 31, 2002. Retrieved 2012-01-10.
NTFS Compression". Retrieved 2011-03-16.
^ "Shrinking the gap: carving NTFS-compressed files". Retrieved
^ Middleton, Dennis (20 May 2008). "Understanding
Ntdebugging Blog. Microsoft.
NTFS Works". 2003-03-28. Retrieved 2011-10-24.
^ Masiero, Manuel (2011-12-01). "Should You Compress Data On Your
SSD?". Tom's Hardware. Bestofmedia Group. Retrieved 2013-04-05.
^ "Disk Concepts and Troubleshooting". Microsoft. Retrieved
^ "Read-Only Filegroups and Compression". SQL Server 2008 Books
Online. Microsoft. November 2009. Retrieved 2010-04-20.
^ "Best practices for
NTFS compression in Windows." Microsoft
Knowledge Base. Retrieved on 2005-08-18.
^ "Sparse Files". MSDN. Microsoft. 12 October 2013. Retrieved 21
^ Kandoth, Suresh B. (4 March 2009). "Sparse
File Errors: 1450 or 665
due to file fragmentation: Fixes and Workarounds". CSS SQL Server
Engineers. Microsoft. Retrieved 21 October 2013.
^ "Sparse Files and Disk Quotas".
MSDN Library. Microsoft. 12 October
2013. Retrieved 21 October 2013.
^ "Designing a
Shadow Copy Strategy". TechNet Library. Microsoft. 28
March 2003. Retrieved 2008-01-15.
^ cfsbloggers (July 14, 2006). "How restore points and other recovery
Windows Vista are affected when you dual-boot with Windows
XP". The Filing Cabinet. Retrieved 2007-03-21.
^ "Transactional NTFS". MSDN. Microsoft. Retrieved 2007-02-02.
Transactional NTFS (TxF)". Windows Dev Center (MSDN). Microsoft.
Retrieved 24 May 2015.
^ a b "How Security Descriptors and Access Control Lists Work".
TechNet. Microsoft. Retrieved 4 September 2015.
^ Morello, John (February 2007). "Security Watch Deploying EFS: Part
1". Technet Magazine. Microsoft. Retrieved 2009-01-25.
^ "How EFS Works".
Windows 2000 Resource Kit. Microsoft. Retrieved 25
^ "Chapter 18 – Choosing a
File System". MS
Windows NT Workstation
4.0 Resource Guide. Microsoft. Retrieved 25 February 2014.
^ "Naming Files, Paths, and Namespaces". MSDN. Microsoft. Naming
Conventions. Retrieved 25 February 2014.
NTFS Partition Boot Sector Information on structure of the boot
^ Boot Sector Additional information on structure of the boot sector.
Note that the sample values are in byte order.
File Table". MSDN. July 2, 2012.
File Table (MFT). Information on structure of MFT file.
^ Since Windows XP, it is very difficult to view a listing of these
files: they exist in the root directory's index, but the Win32
interface filters them out. In NT 4.0, the command line dir command
would list the metafiles in the root directory if /a were specified.
In Windows 2000, dir /a stopped working, but dir /a $MFT worked.
^ a b "OEM Support Tools Phase 3 Service Release 2 Availability".
Microsoft Corporation. 2007-02-21. Retrieved 2010-06-16. Windows NT
File System (NTFS)
File Sector Information Utility [...] A tool used
to dump information about an
^ blogs.technet.com: Jeff Hughes, The Four Stages of
Microsoft KB: A heavily fragmented file in an
NTFS volume may not
grow beyond a certain size (2012)
^ "Beating the Daylight Saving Time bug and getting correct file
modification times Archived 2004-11-14 at the Wayback Machine." The
^ cfsbloggers (July 14, 2006). "How restore points and other recovery
Windows Vista are affected when dual-booting with Windows
XP". The Filing Cabinet. Retrieved 2007-03-21.
^ "How to Convert FAT Disks to NTFS".
2001-10-25. Retrieved 2007-08-27.
^ "How to use Convert
.exe to convert a partition to the
Microsoft Corporation. 2007-02-12. Retrieved
NTFS for Mac". Tuxera. August 30, 2011. Retrieved September
NTFS for Mac OS X, communication channel between Mac OS X and
Windows". Paragon Software Group. Retrieved September 20, 2011.
^ Seagate Read/Write
NTFS driver for Mac OS X Archived 2011-02-10 at
the Wayback Machine.
^ Alvares, Milind (2 October 2009). "Snow Leopard's hidden NTFS
read/write support". Archived from the original on 10 August 2010.
Retrieved 18 September 2010.
BSD adds fuse(4) support for adding file systems in userland".
BSD Journal. 2013-11-08. Retrieved 2013-11-08.
^ "ntfs_3g-2014.2.15 – FUSE
NTFS driver with read/write support".
BSD ports. 2014-01-05. Retrieved 2015-02-14.
NTFS-3G Stable Read/Write Driver". 2009-07-25.
^ "Avira NTFS4DOS Personal". Archived from the original on June 19,
2010. Retrieved 2009-07-25. CS1 maint: BOT: original-url status
^ Download of NTFS4DOS.EXE
NTFS driver for DOS at Softpedia.com
Bolosky, William J.; Corbin, Scott; Goebel, David; Douceur, John R. (2
December 2008). "Single Instance Storage in Windows 2000" (PDF).
Custer, Helen (1994). Inside the
File System. Microsoft
Press. ISBN 978-1-55615-660-1.
Nagar, Rajeev (1997).
File System Internals: A Developer's
Guide. O'Reilly. ISBN 978-1-56592-249-5.
NTFS Technical Reference".
Microsoft TechNet. Microsoft. 28 March
Microsoft Windows components
System Policy Editor
Windows Error Reporting
Alarms & Clock
Fax and Scan
Movies & TV
Windows To Go
Windows Story Remix
Windows XP visual styles
Service Control Manager
Multimedia Class Scheduler
Wireless Zero Configuration
Roaming user profiles
Distributed Transaction Coordinator
Windows Media Services
Rights Management Services
Remote Desktop Services
Network Access Protection
Remote Differential Compression
Print Services for UNIX
Remote Installation Services
Windows Deployment Services
System Resource Manager
Architecture of Windows NT
Desktop Window Manager
Enhanced Write Filter
Graphics Device Interface
I/O request packet
Kernel Transaction Manager
Logical Disk Manager
Open XML Paper Specification
Security Account Manager
Server Message Block
System Idle Process
Security and Maintenance
Data Execution Prevention
Kernel Patch Protection
Mandatory Integrity Control
Protected Media Path
User Account Control
User Interface Privilege Isolation
Virtual DOS machine
Windows on Windows
Windows Subsystem for Linux
COM Structured storage
Universal Windows Platform
Windows Mixed Reality
Backup and Restore
Food & Drink
Help and Support Center
Health & Fitness
Mobile Device Center
Media Control Interface
Next-Generation Secure Computing Base
Video for Windows
Windows Services for UNIX
Windows System Assessment Tool
Spun off to
Comparison of file systems
IBM General Parallel
Flash memory and SSD
Pseudo and virtual
Execute in place
Extended file attributes
File change log
Access control list
File system API
Virtual file system