Editing NTFS (section)

== Structure ==
NTFS is made up of several components including: a partition boot sector (PBS) that holds boot information; the master file table that stores a record of all files and folders in the filesystem; a series of meta files that help structure meta data more efficiently; data streams and locking mechanisms.

Internally, NTFS uses [[B-tree]]s to index file system data. A [[journaling file system|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 systems.<ref>{{cite web |title=Chapter 18 – Choosing a File System|url=https://learn.microsoft.com/en-us/previous-versions//cc750355(v=technet.10)|work=MS Windows NT Workstation 4.0 Resource Guide|date=20 February 2014 |publisher=[[Microsoft]]|access-date=25 January 2025}}</ref>

NTFS allows any sequence of 16-bit values for name encoding (e.g. file names, stream names or index names) 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 [[Integer (computer science)#Short integer|short]] values, not restricted to those in the Unicode standard). In Win32 namespace, any UTF-16 code units are case insensitive whereas in POSIX namespace they are case sensitive. File names 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 <code>[[#Master File Table|$MFT]]</code>, <code>$MFTMirr</code>, <code>$LogFile</code>, <code>$Volume</code>, <code>$AttrDef</code>, <code>.</code> (dot), <code>$Bitmap</code>, <code>$Boot</code>, <code>$BadClus</code>, <code>$Secure</code>, <code>$UpCase</code>, and <code>$Extend</code>.<ref name="How NTFS Works"/> <code>.</code> (dot) and <code>$Extend</code> are both directories; the others are files. The NT kernel limits full paths to 32,767 UTF-16 code units. There are some additional restrictions on code points and file names.<ref>{{cite web |title=Naming Files, Paths, and Namespaces|url=https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions|website=[[Microsoft Learn]]|date=28 August 2024 |publisher=[[Microsoft]]|access-date=25 January 2025|at=Naming Conventions}}</ref>

=== {{Anchor|PBS}} Partition Boot Sector (PBS) ===
{{clear}}
{| class="wikitable sortable plainrowheaders"
|+ NTFS boot sector contents<ref>{{cite web|url=http://www.ntfs.com/ntfs-partition-boot-sector.htm|title=NTFS. Partition Boot Sector|website=Ntfs.com  |access-date=22 September 2018}}</ref><ref>{{cite web|url=https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc976796(v=technet.10)|title=Boot Sector|website=[[Microsoft Learn]] |at=Table 1.13 BPB and Extended BPB Fields on NTFS Volumes |date=September 11, 2008 |access-date=22 September 2018}}</ref> (All values except strings are stored in [[endianness|little endian]] order.)
! scope="col" | Byte offset
! scope="col" | Field length
! scope="col" | Typical value
! colspan="2" |Field name
! scope="col" | Purpose
|-
! scope="row" | 0x00
| 3 bytes
| 0xEB5290
| colspan="2" |x86 [[JMP (x86 instruction)|JMP]] and [[NOP (code)#Machine_language_instructions|NOP]] instructions
| Causes execution to continue after the data structures in this boot sector.
|-
! scope="row" | 0x03
| 8 bytes
| "<code>NTFS&ensp;&ensp;&ensp;&ensp;</code>"<br /><small>Word "NTFS" followed by four trailing spaces (0x20)</small>
| colspan="2" |OEM ID
| This is the magic number that indicates this is an NTFS file system.
|-
! scope="row" | 0x0B
|style='background: #ADD8E6'| 2 bytes
|style='background: #ADD8E6'| 0x0200
| rowspan="11" style="background: #ADD8E6" | BPB
|style='background: #ADD8E6'| Bytes per sector
|style='background: #ADD8E6'| The number of bytes in a disk sector.
|-
! scope="row" | 0x0D
|style='background: #ADD8E6'| 1 byte
|style='background: #ADD8E6'| 0x08
|style='background: #ADD8E6'| Sectors Per Cluster
|style='background: #ADD8E6'| The number of sectors in a cluster. If the value is greater than 0x80, the amount of sectors is 2 to the power of the absolute value of considering this field to be negative.
|-
! scope="row" | 0x0E
|style='background: #ADD8E6'| 2 bytes
|style='background: #ADD8E6'| 0x0000
|style='background: #ADD8E6'| Reserved Sectors, unused
|style='background: #ADD8E6'| 
|-
! scope="row" | 0x10
|style='background: #ADD8E6'| 3 bytes
|style='background: #ADD8E6'| 0x000000
|style='background: #ADD8E6'| Unused
|style='background: #ADD8E6'| This field is always 0
|-
! scope="row" | 0x13
|style='background: #ADD8E6'| 2 bytes
|style='background: #ADD8E6'| 0x0000
|style='background: #ADD8E6'| Unused by NTFS
|style='background: #ADD8E6'| This field is always 0
|-
! scope="row" | 0x15
|style='background: #ADD8E6'| 1 byte
|style='background: #ADD8E6'| 0xF8
|style='background: #ADD8E6'| Media Descriptor
|style='background: #ADD8E6'| The type of drive. 0xF8 is used to denote a hard drive (in contrast to the several sizes of floppy).
|-
! scope="row" | 0x16
|style='background: #ADD8E6'| 2 bytes
|style='background: #ADD8E6'| 0x0000
|style='background: #ADD8E6'| Unused
|style='background: #ADD8E6'| This field is always 0
|-
! scope="row" | 0x18
|style='background: #ADD8E6'| 2 bytes
|style='background: #ADD8E6'| 0x003F
|style='background: #ADD8E6'| Sectors Per Track
|style='background: #ADD8E6'| The number of disk sectors in a drive track.
|-
! scope="row" | 0x1A
|style='background: #ADD8E6'| 2 bytes
|style='background: #ADD8E6'| 0x00FF
|style='background: #ADD8E6'| Number Of Heads
|style='background: #ADD8E6'| The number of heads on the drive.
|-
! scope="row" | 0x1C
|style='background: #ADD8E6'| 4 bytes
|style='background: #ADD8E6'| 0x0000003F
|style='background: #ADD8E6'| Hidden Sectors
|style='background: #ADD8E6'| The number of sectors preceding the partition.
|-
! scope="row" | 0x20
|style='background: #ADD8E6'| 4 bytes
|style='background: #ADD8E6'| 0x00000000
|style='background: #ADD8E6'| Unused
|style='background: #ADD8E6'| Not used by NTFS
|-
! scope="row" | 0x24
|style='background: #ADD8FF'| 4 bytes
|style='background: #ADD8FF'| 0x00800080
| rowspan="10" style="background: #ADD8FF" | EBPB
|style='background: #ADD8FF'| Unused
|style='background: #ADD8FF'| Not used by NTFS
|-
! scope="row" | 0x28
|style='background: #ADD8FF'| 8 bytes
|style='background: #ADD8FF'| 0x00000000007FF54A
|style='background: #ADD8FF'| Total sectors
|style='background: #ADD8FF'| The partition size in sectors.
|-
! scope="row" | 0x30
|style='background: #ADD8FF'| 8 bytes
|style='background: #ADD8FF'| 0x0000000000000004
|style='background: #ADD8FF'| $MFT cluster number
|style='background: #ADD8FF'| The cluster that contains the Master File Table
|-
! scope="row" | 0x38
|style='background: #ADD8FF'| 8 bytes
|style='background: #ADD8FF'| 0x000000000007FF54
|style='background: #ADD8FF'| $MFTMirr cluster number
|style='background: #ADD8FF'| The cluster that contains a backup of the Master File Table
|-
! scope="row" | 0x40
|style='background: #ADD8FF'| 1 byte
|style='background: #ADD8FF'| 0xF6
|style='background: #ADD8FF'| Bytes or Clusters Per File Record Segment
|style='background: #ADD8FF'| A positive value denotes the number of clusters in a File Record Segment. A negative value denotes the amount of bytes in a File Record Segment, in which case the size is 2 to the power of the absolute value. (0xF6 = -10 → 2<sup>10</sup> = 1024).
|-
! scope="row" | 0x41
|style='background: #ADD8FF'| 3 bytes
|style='background: #ADD8FF'| 0x000000
|style='background: #ADD8FF'| Unused
|style='background: #ADD8FF'| This field is not used by NTFS
|-
! scope="row" | 0x44
|style='background: #ADD8FF'| 1 byte
|style='background: #ADD8FF'| 0x01
|style='background: #ADD8FF'| Bytes or Clusters Per Index Buffer
|style='background: #ADD8FF'| A positive value denotes the number of clusters in an Index Buffer. A negative value denotes the amount of bytes and it uses the same algorithm for negative numbers as the "Bytes or Clusters Per File Record Segment."
|-
! scope="row" | 0x45
|style='background: #ADD8FF'| 3 bytes
|style='background: #ADD8FF'| 0x000000
|style='background: #ADD8FF'| Unused
|style='background: #ADD8FF'| This field is not used by NTFS
|-
! scope="row" | 0x48
|style='background: #ADD8FF'| 8 bytes
|style='background: #ADD8FF'| 0x1C741BC9741BA514
|style='background: #ADD8FF'| Volume Serial Number
|style='background: #ADD8FF'| A unique random number assigned to this partition, to keep things organized.
|-
! scope="row" | 0x50
|style='background: #ADD8FF'| 4 bytes
|style='background: #ADD8FF'| 0x00000000
|style='background: #ADD8FF'| Checksum, unused
|style='background: #ADD8FF'| Supposedly a checksum.
|-
! scope="row" | 0x54
| 426 bytes
|
| colspan="2" |Bootstrap Code
| The code that loads the rest of the operating system. This is pointed to by the first 3 bytes of this sector.
|-
! scope="row" | 0x01FE
| 2 bytes
| 0xAA55
| colspan="2" |End-of-sector Marker
| This flag indicates that this is a valid boot sector.
|}

This boot partition format is roughly based upon the earlier [[File Allocation Table|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 do not make sense or are not 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 ([[Logical block addressing|LBA]]) to the $MFT, which is described below.

=== {{Anchor|MFT}} Master File Table === <!--'Master File Table' redirects here-->
In NTFS, all file, directory and [[#Metafiles|metafile]] data—file name, creation date, access permissions (by the use of [[access control list]]s), and size—are stored as metadata in the '''Master File Table'''<!--boldface per WP:R#PLA--> ('''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]] and the [[Windows Search]]. This also enables fast file search software to locate named local files and folders included in the MFT very quickly, without requiring any other index.

The MFT structure supports algorithms which minimize [[file system fragmentation|disk fragmentation]].<ref>{{cite web |url=https://learn.microsoft.com/en-us/windows/win32/fileio/master-file-table |title=Master File Table (Local File Systems) |date=August 28, 2024 |website=[[Microsoft Learn]] |publisher=[[Microsoft]]}}</ref> A directory entry consists of a filename and a "file ID" (analogous to the [[inode number]]), which is the record number representing the file in the Master File Table. The file ID also contains a reuse count to detect stale references. While this strongly resembles the W_FID of [[Files-11]], other NTFS structures radically differ.

A partial copy of the MFT, called the MFT mirror, is stored to be used in case of corruption.<ref>{{Cite web|date=2009-06-05|title=Forensics: What is the MFT Mirror?|url=https://whereismydata.wordpress.com/2009/06/05/forensics-what-is-the-mft-mirror/|access-date=2021-07-30|website=Where is Your Data?|language=en}}</ref> If the first record of the MFT is corrupted, NTFS reads the second record to find the MFT mirror file. Locations for both files are stored in the boot sector.<ref>{{cite web|url=http://ntfs.com/ntfs-mft.htm|title=NTFS Master File Table (MFT)|website=Ntfs.com|access-date=22 September 2018}}</ref>

=== Metafiles ===
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.<ref>{{cite web |url= http://www.cse.scu.edu/~tschwarz/coen252_07Fall/Lectures/NTFS.html |title= COEN 252 Computer Forensics NTFS |publisher= Faculty of Organization and Informatics University of Zagreb |last= Schwarz |first= Thomas |access-date=May 30, 2019|archive-url=https://web.archive.org/web/20210227190756/http://www.cse.scu.edu/~tschwarz/coen252_07Fall/Lectures/NTFS.html|archive-date=2021-02-27|url-status=dead}}</ref> 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.

{| class="wikitable sortable plainrowheaders"
|+ MFT (entries 0–26 are the NTFS metafiles)
! scope="col" | Segment number
! scope="col" | File name
! scope="col" | Purpose
|-
! scope="row" | 0
| <code>$MFT</code>
| Describes all files on the volume, including file names, timestamps, stream names, and lists of cluster numbers where data streams reside, indexes, [[security identifier]]s, and file attributes like "read only", "compressed", "encrypted", etc.
|-
! scope="row" | 1
| <code>$MFTMirr</code>
| Duplicate of the first vital entries of {{mono|$MFT}}, usually 4 entries (4 [[kilobyte]]s).
|-
! scope="row" | 2
| <code>$LogFile</code>
| Contains transaction log of file system metadata changes.
|-
! scope="row" | 3
| <code>$Volume</code>
| Contains information about the volume, namely the volume object identifier, [[volume label]], file system version, and volume flags (mounted, chkdsk requested, requested {{mono|$LogFile}} 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 {{mono|$OBJECT_ID}} record; the volume label is stored in a {{mono|$VOLUME_NAME}} record, and the remaining volume data is in a {{mono|$VOLUME_INFORMATION}} record. Note: volume serial number is stored in file {{mono|$Boot}} (below).
|-
! scope="row" | 4
| <code>$AttrDef</code>
| A table of MFT attributes that associates numeric identifiers with names.
|-
! scope="row" | 5
| <code>.</code>
| [[Root directory]]. Directory data is stored in {{mono|$INDEX_ROOT}} and {{mono|$INDEX_ALLOCATION}} attributes both named {{mono|$I30}}.
|-
! scope="row" | 6
| <code>$Bitmap</code>
| An array of bit entries: each bit indicates whether its corresponding cluster is used (allocated) or free (available for allocation).
|-
! scope="row" | 7
| <code>$Boot</code>
| [[Volume boot record]] (VBR). This file is always located at the first clusters on the volume. It contains [[Bootstrapping#Computing|bootstrap code]] (see [[NTLDR]]/[[Windows Boot Manager|BOOTMGR]]) and a [[BIOS parameter block]] including a [[volume serial number]] and cluster numbers of {{mono|$MFT}} and {{mono|$MFTMirr}}.
|-
! scope="row" | 8
| <code>$BadClus</code>
| A file that contains all the clusters marked as having [[bad sector]]s. 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 {{mono|$Bad}} and contains all clusters on the volume not in the first stream.
|-
! scope="row" | 9
| <code>$Secure</code>
| [[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: {{mono|$SII}} ''(Standard_Information ID)'' and {{mono|$SDH}} ''([[Security Descriptor]] Hash)'', which index the stream named {{mono|$SDS}} containing actual ACL table).<ref name="insidewin2kntfs"/>
|-
! scope="row" | 10
| <code>$UpCase</code>
| A table of unicode uppercase characters for ensuring case-insensitivity in Win32 and DOS namespaces.
|-
! scope="row" | 11
| <code>$Extend</code>
| A file system directory containing various optional extensions, such as {{mono|$Quota}}, {{mono|$ObjId}}, {{mono|$Reparse}} or {{mono|$UsnJrnl}}.
|-
! scope="row" | 12–23
| colspan=2 |Reserved for {{mono|$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.
|-
! scope="row" | 24
| <code>$Extend\$Quota</code>
| Holds disk quota information. Contains two index roots, named {{mono|$O}} and {{mono|$Q}}.
|-
! scope="row" | 25
| <code>$Extend\$ObjId</code>
| Holds [[#Distributed Link Tracking (DLT)|link tracking]] information. Contains an index root and allocation named {{mono|$O}}.
|-
! scope="row" | 26
| <code>$Extend\$Reparse</code>
| Holds [[reparse point]] data (such as [[symbolic link]]s). Contains an index root and allocation named {{mono|$R}}.
|-
! scope="row" | 27–
| colspan=2 |Beginning of regular file entries.
|}

These metafiles are treated specially by Windows, handled directly by the <code>NTFS.SYS</code> driver and are difficult to directly view: special purpose-built tools are needed.{{efn|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 <code>dir</code> command would list the metafiles in the root directory if <code>/a</code> were specified. In Windows 2000, {{code|2=dosbatch|dir /a}} stopped working, but {{code|2=dosbatch|dir /a \$MFT}} worked.}} As of Windows 7, the NTFS driver completely prohibits user access, resulting in a [[BSoD]] whenever an attempt to execute a metadata file is made. One such tool is the nfi.exe ("NTFS 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: {{code|nfi.exe c:\$MFT}}<ref name="support.microsoft.com">{{cite web |title= OEM Support Tools Phase 3 Service Release 2 Availability |url= http://support.microsoft.com/kb/253066/ |publisher= Microsoft Corporation |date= 2007-02-21 |quote= Windows NT File System (NTFS) File Sector Information Utility ... A tool used to dump information about an NTFS volume |access-date= 2010-06-16|archive-url= https://web.archive.org/web/20150223112102/http://support.microsoft.com/kb/253066/en-us |archive-date=2015-02-23}}</ref> Another way to bypass the restriction is to use [[7-Zip]]'s file manager and go to the low-level NTFS path <code>\\.\X:\</code> (where <code>X:\</code> resembles any drive/partition). Here, 3 new folders will appear: <code>$EXTEND</code>, <code>[DELETED]</code> (a pseudo-folder that 7-Zip uses to attach files deleted from the file system to view), and <code>[SYSTEM]</code> (another pseudo-folder that contains all the NTFS metadata files). This trick can be used from removable devices ([[USB]] flash drives, [[external hard drives]], [[SD card]]s, etc.) inside Windows, but doing this on the active partition requires offline access (namely [[WinRE]]).

=== 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&nbsp;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 {{mono|$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 {{mono|$AttrDef}}, some attributes can be either resident or non-resident. The {{mono|$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 attribute types.
** This is the case for the {{mono|$STANDARD_INFORMATION}} attribute that is stored as a fixed-size record and contains the [[timestamp]]s and other basic single-bit attributes (compatible with those managed by [[File Allocation Table|FAT]] in DOS or [[Windows 9x]]).
* 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 other directory on the same volume. There it must have its own MFT record and its own [[security descriptor]]s and attributes that reference the MFT record number for this 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 {{mono|$DATA}} but with an anonymous name, and the ADSs are similar but must be named.
* On the other hand, the default data stream of directories has a distinct type, but are not anonymous: they have an attribute name ("{{mono|$I30}}" in NTFS 3+) that reflects its indexing format.

All attributes of a given file may be displayed by using the nfi.exe ("NTFS File Sector Information Utility") that is freely distributed as part of the Microsoft "OEM Support Tools".<ref name="support.microsoft.com"/>

Windows system calls may handle alternate data streams.<ref name="How NTFS Works"/> Depending on the operating system, utility and remote file system, a file transfer might silently strip data streams.<ref name="How NTFS Works"/> 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.<ref name="How NTFS Works"/>

=== 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.<ref>{{cite web|url=http://blogs.technet.com/b/askcore/archive/2009/10/16/the-four-stages-of-ntfs-file-growth.aspx|title=The Four Stages of NTFS File Growth|access-date=22 September 2018|archive-url=https://web.archive.org/web/20180923052803/https://blogs.technet.microsoft.com/askcore/2009/10/16/the-four-stages-of-ntfs-file-growth/|archive-date=23 September 2018|url-status=dead}}</ref> 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, NTFS stores 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 {{mono|$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 {{mono|$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 descriptor]]s), 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 {{val|1|ul=KB}} MFT record can store about 100 such data runs. However, as the {{mono|$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 {{val|10|ul=GB}}.<ref>{{cite web |url=https://support.microsoft.com/en-us/topic/a-heavily-fragmented-file-in-an-ntfs-volume-may-not-grow-beyond-a-certain-size-da1c0dfd-a5a1-90b4-4bf7-b65b13ef9d35 |title=A heavily fragmented file in an NTFS volume may not grow beyond a certain size |access-date=2021-05-19 |url-status=live |archive-url=https://web.archive.org/web/20210506185845/https://support.microsoft.com/en-us/topic/a-heavily-fragmented-file-in-an-ntfs-volume-may-not-grow-beyond-a-certain-size-da1c0dfd-a5a1-90b4-4bf7-b65b13ef9d35 |archive-date=2021-05-06}}</ref>

The 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 {{val|74.5|u=GB}} partition NTFS formats with 19,543,064 clusters of {{val|4|u=KB}}. Subtracting system files (a {{val|64|ul=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 files.

=== Opportunistic locks ===
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.<ref>{{cite web |url=http://msdn.microsoft.com/en-us/library/cc308442.aspx |title=How Oplocks function in the Windows Environment: Overview |access-date=2018-12-19 |url-status=dead |archive-url=https://web.archive.org/web/20100823125612/http://msdn.microsoft.com/en-us/library/cc308442.aspx |archive-date=2010-08-23}}</ref> 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 caching).
* 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.<ref>{{cite web|url=https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff383236(v=ws.10)|title=What's New in NTFS|website=[[Microsoft Learn]]|date=2 July 2012 |access-date=25 January 2025}}</ref>

=== Time ===
Windows NT and its descendants keep internal timestamps as [[UTC]] and make the appropriate conversions for display purposes; all NTFS timestamps are in UTC.{{Citation needed|reason=UTC seems unlikely, as it relies on leap seconds, which Windows is known not to do|date=February 2020}}

For historical reasons, the versions of Windows that do not support NTFS all keep time internally as local zone time, and therefore so does the [[File Allocation Table|FAT]] file system. This means that when files are copied or moved between NTFS and FAT 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&nbsp;hours in any given 12&nbsp;months.<ref>{{cite web |url=https://www.codeproject.com/Articles/1144/Beating-the-Daylight-Savings-Time-Bug-and-Getting |title=Beating the Daylight Saving Time bug and getting correct file modification times |first=Jonathan |last=Gilligan |date=28 May 2001 |website=The Code Project}}</ref>

This problem is further exacerbated for any computers for which local time zone changes sometimes (e.g. due to moving the computer from one time zone to another, as often happens with laptops and other portable devices).