Editing NTFS (section)

=== 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]]).