A B C D E F G H I J K L M N O P Q R S T U V W X Y Z | View All

Master File Table (MFT)

Once a volume has been formatted, internal filesystem information describing how and where files and folders are stored on a filesystem are created. For example, the boot sectors and Master File Table (MFT), in addition to other metadata files, a relational database on a NTFS filesystem are all types of metadata. Loss or corruption of metadata used to implement the filesystem structure will render the filesystem inaccessible, although available, to the operating system. NTFS reserves the first 16 records of the MFT for metadata files (approximately 1MB). The remaining records of the MFT contain the file and folder records for each file and folder on the volume. The MFT also includes a separate file record for the MFT itself. NTFS allocates space for each MFT record based on the cluster size of the file. The attributes of the file are written to the allocated space in the MFT. Besides file attributes, each file record contains information about the position of the file record in the MFT. Each file usually uses one file record. However, if a file has a large number of attributes or becomes highly fragmented, it may need more than one file record. If this is the case, the first record for the file, the base file record stores the location of the other file records required by the file. Small files and folder (typically 1,500 bytes or smaller) are entirely contained within the file’s MFT record while larger folders are organised into B-tree (or b-tree) structures and have records with pointers to external clusters that contain folder entries that cannot be contained within the MFT structure.
The data segment location for both MFT and the backup MFT, $Mft and $MftMirr respectively, are recorded in the boot sector. If the first MFT record is corrupted, NTFS reads the second record to find the MFT mirror file. A duplicate of the NTFS boot sector is located at the end of the volume.
The MFT - the heart of the NTFS volume structure is implemented as an array of file records - is a database NTFS system file, the first file on an NTFS volume which tracks the contents of files and folders on an NTFS volume. The MFT is a table whose rows correspond to file records of files on the volume and whose columns correspond to the file attributes of each file. NTFS makes no special efforts to keep files contiguous, other than to reserve a region of disk space for the MFT zone for the MFT helping it stay contiguous, but it, too, can become fragmented.
In NTFS, all data stored on a volume is contained in files, including the data structures used to locate and retrieve files, the bootstrap data, and the bitmap that records the allocation state of the entire volume (the NTFS metadata). Storing everything in files allows the filesystem to easily locate and maintain the data, and each separate file can be protected by a security descriptor. In addition, if particular parts of the hard disk drive become damaged, NTFS can relocate the metadata files to prevent the disk format from becoming inaccessible.
In addition to the MFT, each NTFS volume includes a set of metadata files containing the information that is used to implement the filesystem structure. Each of these NTFS metadata files has a name that begins with ($), although the signs are hidden. For example, the filename of the MFT is $Mft.
Usually, each MFT record corresponds to a different file. If the file has a large number of attributes or becomes highly fragmented, however, more than one record may be required for a single file. In such a case, the MFT first record, which stores the location of the others, is called the base file record.
As the MFT stores information about itself, the first 16KBs (first 16 entries) of the MFT for NTFS are reserved for metadata files of size 1KB. Each are used to describe the MTF in ascending order starting at, but excluding file zero (0), is as follows: $Mft (MFT – contains one base file record for each file and folder on an NTFS volume); $MftMirr (MFT mirror, guarantees access to the MFT in case of a single-sector failure. It is a duplicate image of the first four (4) records of the MFT); $LogFile (Log file contains a list of transaction steps used for NTFS recoverability and its size is dependent on the size of the volume); $Volume (Volume file contains information about the volume, i.e., label, version); $AttrDef (Attribute definition table lists attribute names, numbers and descriptors); \ (Root directory); $Bitmap (Volume cluster allocation file showing free and unused space); $Boot (Boot sector including the BIOS Parameter Block (BPB) used to mount the volume and additional bootstrap loader code used if the volume is bootable); $BadClus (Bad-cluster file contains bad clusters for a volume); $Secure (Security settings file contains unique security descriptors for all files within a volume); $UpCase (Uppercase character mapping converts lowercase characters to matching Unicode uppercase characters); $Extend (Extended metadata directory, used for various optional extensions such as quotas, reparse point data, and object identifiers); (file 12 through to 15 are reserved for future use); Used files and directories.
NTFS’s performance is now similar to FAT for Windows XP and Windows Server 2003 compared to Windows 2000 because the $LogFile and $Bitmap metadata files on newly formatted NTFS volumes are located in a different position on the disk. (The MFT record numbers do not change.) This new metadata file locations for $LogFile and $Bitmap have improved performance by 5 to 8 per cent.
When NTFS first accesses a volume, it must first mount it – that is, read metadata from the disk and construct internal data structures so that it can process application filesystem accesses. To mount the volume, NTFS looks in the boot sector to find the hard disk drive’s address of the MFT. The MFT’s first file record is the entry in the table ($Mft); the second file record points to a file location in the middle of the disk called the MFT mirror ($Mft mirror) that contains a duplicate of the first few rows of the MTF, aforementioned. This partial MFT copy is used to locate metadata files if part of the MFT file cannot be read for whatever reason.
Once NTFS finds the first file record ($Mft), it obtains the VCN-to-LCN mapping information in the record’s data attribute and stores it in memory. Each run (resident and non-resident attribute) has a VCN-to-LCN mapping and a run length because that is all the information necessary to locate an LCN for any VCN. To save space, however, the MFT file record’s data attribute, which contains VCN-to-LCN mappings, records only one mapping for each run, rather than for each cluster. This mapping information tells NTFS where the runs composing the MFT are located on the disk. NTFS then processes the MFT records for several more metadata files and opens the files. NTFS performs its filesystem recovery operation, and finally, it opens its remaining metadata files. The volume is now ready for user access.
As the system runs, NTFS writes to another important file, the log file ($LogFile). NTFS uses the log file to record all operations that affect the NTFS volume structure, including file creation or any commands, such as Copy, that alters the directory structure. The log file is used to recover an NTFS volume after a system failure.
Another entry in the MFT is reserved for the root directory (\). Its file record contains an index of the files and directories stored in the root of the NTFS directory structure. When NTFS is first asked to open a file, it begins its search for the file in the root directory’s file record. After opening a file, NTFS stores the file’s MFT file reference so that it can directly access the file’s MFT record when it reads and writes to the file later.
NTFS records the allocation state of the volume in the bitmap file (filename: $Bitmap). The data attribute for the bitmap file contains a bitmap, each of whose bits represent a cluster on the volume, identifying whether the cluster is free or has been allocated a file.
The central metadata security file (filename: $Secure) stores the volume-wide security descriptor database. NTFS files and directories have individually settable security descriptors, but to conserve space, NTFS stores the settings in a common file, allowing files and directories that have the same security settings to reference the same security descriptor. In most environments, entire directory trees have the same security settings, so this optimisation provides a significant saving is lost space.
Another system file startup file (#2) is the boot.ini file (filename: $Boot), which stores the Windows bootstrap code. For the system to boot, the bootstrap code must be located at a specific disk address. During formatting, however, the format command defines the area as a file by creating a file record for it. Creating the boot file allows NTFS to adhere to its rule of making everything on the disk a file. The boot file as well as NTFS metadata files can be individually protected by means of the security descriptors that are applied to all Windows objects. Using this “everything on the disk is a file” model also means that the bootstrap can be modified by normal file I/O, although the boot file is protected from editing.
NTFS also maintains a bad-cluster file (filename: $BadClus) for recording bad areas on the disk volume know as the volume file (filename: $Volume), which contains the volume name, the version of NTFS for which the volume is formatted, and a bit that when set signifies that a disk corruption has occurred and must be repaired by the Chkdsk utility. The uppercase file (filename: $UpCase) includes the translation table between lowercase and uppercase characters. NTFS maintains a file containing an attribute definition table (filename: $AttrDef) that defines the attribute types supported on the volume and indicates whether they can be indexed, recovered during a system recovery operation and so forth.
NTFS stores several metadata files in the extensions (directory name: $Extend, a sparse file) metadata directory, including the object identifier file (filename: $Quota), the change journal file (filename: $UsnJrnl, a sparse file), and the reparse point file (filename: $Reparse). These files store information related to optional features in NTFS. The object identifier file stores file object IDs, the quota file stores quota limits and behaviour information on volumes that have quota enabled, the change journal file records file and directory changes, and the reparse point file stores information about which files and directories on the volume include reparse point data.

System File

File Name

MFT Record

Purpose of File

Master File Table (1)

$Mft

Contains one base file record for each file and folder on a NTFS volume. If the allocation information for a file or folder is too large to fit within a single record, other file records are allocated as well.

Master File Table (2)

$MftMirr

A duplicate image of the first four records of MTF (1). This file guarantees access to the MFT in case of a single-sector failure.

Log file

$LogFile

Contains a list of transaction steps used for NTFS recoverability. Log file size depends on the volume size and can be as large as 4MB. It is used by Win2K/XP/Server 2003, for example, to restore consistency to NTFS after a system failure.

Volume

$Volume

Contains information about the volume, such as the volume label and volume version.

Attribute definition

$AttrDef

A table of attribute names, numbers, and descriptors.

Root file name index

The root folder.

Cluster bitmap

$Bitmap

A representation of the volume showing which clusters are in use.

Boot sector

$Boot

Includes the BPB used to mount the volume, in addition the bootstrap loader code used if the volume is bootable.

Bad cluster file

$BadClus

Contains bad clusters for the volume.

Security file

$Secure

Contains unique security descriptors for all files within a volume.

Upcase table

$Upcase

Converts lowercase characters to matching Unicode uppercase characters.

NTFS extension file

$Extend

Used for various optional extensions such as quotas, reparse point data, and object identifiers.

12-15

Reserved for future use.

See: Allocation Unit (or Cluster), Attribute (or Attribute Byte), Attribute List, B-tree (b-tree), Base File Record, BIOS Parameter Block (BPB), Boot Sector, Boot.ini (non-Windows NT-based & Windows NT-based operating system system startup file #2), Check Disk (chkdsk.exe), Cluster (or Allocation Unit), Bootstrap, Bootstrap Loader, Dynamic Cluster Remapping, Log File, Logical Cluster Number (LCNs), Filename, File Record, File Reference Metadata, Metadata File, MFT Mirror ($MFTMirr), Mount, NTFS (New Technology Filesystem), Reparse Data, Reparse Point, Reparse Tag, and Volume.

Master File Table Mirror ($MFTMirr)

An NTFS metadata file (filename: $MFTMirr) located in the middle of the disk that contains a copy of the first few rows of the Master File Table (MFT).
The data segment locations for both the MFT and the backup MFT, $Mft and $MftMirr respectively, are recorded in the boot sector. The $MftMirr is a duplicate image of either the first four records of the $Mft or the first cluster of the $Mft, whichever is largest. If any MFT records in the mirrored range are corrupted or unreadable, NTFS reads the boot sector to find the location of the $MftMirr. NTFS then reads the $MftMirr and uses the information in $MftMirr instead of the information in the MFT. If possible, the correct data from the $MftMirr is written back to the corresponding location in the $Mft.
See: Boot Sector, Metadata, Metadata File, and Master File Table (MFT).

MBR Disk

An MBR disk is a disk that uses the Master Boot Record (MBR) partition style. A partition style is the method that the Windows NT family operating system uses to organise partitions on a disk. All x86-based computers use MBR disks.
See: Master Boot Record (MBR).

Mebibyte (symbol Mi)

A unit of information storage equal to 1,048,576 bytes (1,024*1,024 equals 1Mi). This value was previously called a binary megabyte.
See: Megabyte.

Media (Physical Media)

Any fixed or removable objects (material/medium) that records and stores computer data. Examples include hard disk drives, floppy diskettes, tapes, DVD, and optical discs. WORM means Write Once, Read Many (or Write Once Read Multiple times). It is sometimes used when discussing computer storage media that can be written to once, but read multiple times.
See: Disc & Disk, Fixed Disk (or Hard Disk Drive), and Floppy diskette.

Mega (symbol M or m) – Greek: megas, meaning great

A multiplier indicating one million (1,000,000, or 1.0*10^6) of some unit. Traditionally, mega had been defined as 1,048,576 (1,024 kilobytes, where kilobyte equals 1,024) in disk storage and memory for example (as defined by many BIOSes, FDISK and other disk partitioning programs).
See: Basic Input/Output System (BIOS), FDISK.EXE. and Kilobytes.

Megabyte or Decimal Megabyte (symbol MB or Mb)

A unit of information storage equal to 1,000,000 bytes. The value 1,048,576 bytes has been called a binary megabyte but is now known as a Mebibyte.
See: Mebibyte (symbol Mi)

Metadata – Greek: meta - + Latin: data “information” (or Volume Structure Data; literally “data about data”)

Once a volume has been formatted internal filesystem information describing how and where files are stored on a filesystem. For example, the Master Boot Record’s (MBR’s), master partition boot code (executable instructions), partition tables, Logical Disk Manager (LDM), boot sector, FATs on a FAT filesystems and MFT on a NTFS filesystem are all types of metadata or meta-structures. Loss or corruption of metadata used to implement the filesystem structure will render the filesystem inaccessible, although available, to the operating system. NTFS reserves the first 16 records of the MFT for metadata files (approximately 1MB).
FAT and NTFS use very different on-disk structures to represent the allocation of space for a file. These structures are often referred to as metadata or filesystem overhead. Another kind of overhead associated with FAT and NTFS is related to the fact that both filesystems allocate disk space in clusters of a fixed size. The exact size of these clusters is determined at format time, and is dependent on the size of the volume. Like FAT, NTFS has a certain amount of fixed-size overhead and a certain amount of per-file overhead. To support the advanced features of NTFS, such as recoverability, security, and support for very large volumes, the NTFS metadata overhead is somewhat larger than the FAT metadata overhead. However, because NTFS clusters are smaller than FAT clusters for the same size volume, more data can be stored on a NTFS volume, even without using NTFS compression. When a file’s attribute can fit within the Master File Table (MFT) file record for that file, they are called resident attributes. Information such as a file name and timestamp are always resident attributes. When the information for a file is too large to fit in its MFT file record, some of the file attributes are non-resident. Non-resident attributes are allocated one or more clusters of disk space and are stored as an alternate data stream in the volume.
Metadata is data stored on the volume in support of filesystem format management. It is not typically made accessible to applications. Metadata includes that data that defines the placement of files and directories on a volume, for example.See: Attribute List, Attribute (Resident & Non-Resident), B-tree (b-tree), Base File Record, Boot Sector, FAT (12-, 16-, and 32-bit), File Allocation Table, File Attribute, File Record, File Reference, Filesystem, Logical Disk Manager (LDM) Database, Master File Table (MFT), Metadata Files, NTFS (New Technology Filesystem) , and Partition Table.

Metadata Files

A set of files in each NTFS volume that contains the information used to implement the filesystem structure.
See: Metadata, and NTFS (New Technology Filesystem).

MFM Encoding (Modified Frequency Modulation Encoding)

A method of encoding data on the surface of a disk. The coding of a bit varies by the coding of the proceeding bit to preserve clocking information. Used only by floppy diskette drives for compatibility nowadays because it stores less data than other types of media that using encoding such as RLL.
See: Data, and RLL (Run Length Limited).

MFT Mirror ($MFTMirr)

An NTFS metadata file (filename: $MFTMirr) located in the middle of the disk that contains a copy of the first few rows of the master file table.
See: Master File Table (MFT), Metadata Files, and NTFS (New Technology Filesystem).

Mount

To place a removable tape or disc into a drive. Mount also describes a technique NTFS uses when it first accesses a volume; in this context, to mount means to prepare the volume for use. To mount the volume, NTFS looks in the boot file to find the hard disk drives address of the master file table.
See: Dismount, and Master File Table (MFT), NTFS (New Technology Filesystem), and Volume.

Mount Points

A mechanism that permits the linking of volumes through directories on NTFS volumes, which results in volumes being accessible without any drive letter assignment. What makes mount points possible is reparse point technology.
Mount points are reparse points that store a volume name as reparse data. Using the Disk Management MMC snap-into assign or move path assignments for volumes is an example of a mount point. Mount points can be displayed using the built-in command line tool Mountvol.exe.
The Mount Manager maintains the Mount Manager remote database on every NTFS volume in which the Mount Manager records any mount points defined for the volume. The database file, $MountMgrRemoteDatabase, resides in the NTFS root directory where volumes assigned a drive letter by the Mount Manager are reserved. Mount points move when a disk moves from one system to another and in dual-boot environments. NTFS also keeps track of mount points in the NTFS metadata file \$Extend\$Reparse – this is not available for viewing. NTFS stores mount-point information in the metadata file so that Windows can easily enumerate the mount points defined for a volume when Windows applications, such as Disk Management, requests mount-point definitions.
The Mount Manager device driver (mountmgr.sys) assigns all “persistent” (remain assigned to that volume until it is either deleted or changed manually using Disk Management) drive letters for dynamic disk and basic disk volumes created after Windows is installed, storing drive-letter assignments under HKLM\SYSTEM\MountedDevices (note Windows NT family operating systems store a 4-byte disk signature or volume ID starting within the MBR at offset 0x1B8 (1B8h) which is used to map drive letters to disks in this important registry key. The exception to this rule is that if an online volume (disk) is offline, and a different new volume comes online, it may get the offline volume’s drive letter. Ideally, to keep drive letter assignment intact, keep existing volumes online when introducing new volumes.
Every volume has a volume name entry in the registry, but not every volume necessarily will have an assigned drive letter. The Mounted Devices registry key is not in the Control set and so is not protected by the Last Known Good Configuration boot option.
The data that the registry stores in values for basic disk volumes drive letters and volume names is the Windows NT4-style disk signature and the starting offset of the first partition associated with the volume. However, for dynamic disk volumes it includes the DMIO-internal GUID. When a volume is created, the Mount Manager uses the first unassigned drive letter (if one exits) and eventually updates the MountedDevices registry key. If there are no available drive letters, no drive-letter assignment is made.
A reason for the limit of a directory depth of 32 and a pathname of 256 is to avoid recursion (infinite mount point recursion). Nevertheless, just because Windows assigns a drive letter to a volume does not mean that the volume contains data that has been organised in a filesystem format that Windows recognises. Reparsed points in NTFS make mount points possible.
On rare occasions the system/boot drive letter, default C, can change without user intervention. It will not be possible to change the volume’s drive letter using the Window Disk Management (WDM) MMC snap-in, which would be the preferred method under normal circumstances.
The Registry Editor or its equivalent is necessary; serious problems may occur using the method, described below, incorrectly. There is no guarantee this method, carried out correctly, will work either.

Create an image and backup critical data.
Go to the following subkey: HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices (HKLM is the root key/hive containing all the systemwide configuration subkeys: HARDWARE (hive file path: volatile hive), SAM (hive file path: \Windows\System32\Config\Sam), SECURITY (hive file path: \Windows\System32\Config\Security), SOFTWARE (hive file path: \Windows\System32\Config\Software), and SYSYTEM (hive file path: \Windows\System32\Config\System). This hive key holds most of the information in the registry because it is the placeholder for two other hive keys that are aliased to its subkeys: SAM and SECURITY).
Click on MountedDevices.
Right-click on MountedDevices, and click on Permissions and verify that the key has full Administrative control. This can be changed back later.
Look for \DosDevices\C: (This is the volume with the drive letter C that is not the system/boot volume).
Right-click on \DosDevices\ C:; click on Rename, changing it to a drive letter not in use. The drive letter C is now ready to be reassigned.
Find the \DosDevices\ for the system/boot volume that should be C but isn’t. Right-click on \DosDevices\X:, (X, being the system/boot volume drive letter at this time and is for example purposes only), click on Rename, changing it to C. \DosDevices\X: should now be \DosDevices\ C:.
You can change the volume that was incorrectly C using the method, but it can now be changed using the Windows Disk Management MMC snap-in.

See: Last Known Good Configuration, Logical Disk Manager (LDM) Database, Master Boot Record (MBR), Reparse Data, Reparse Point, Reparse Tag, and Windows Registry.

MSDOS.SYS

One of the DOS/Windows 9x system files required to boot the computer system. It contains the primary DOS routines. Loaded by IO.SYS, it in turn loads COMMAND.COM.
See: IO.SYS.

Multi-Data Stream

Each unit of information with a file under the filesystem NTFS (not supported for FAT filesystems) – including its name, its owner, its timestamps, its contents, and so forth – is implemented as a file attribute (NTFS object attribute). Each attribute consists of a single stream, that is, a simple sequence of bytes. The generic implementation makes it easy to add more attributes, and consequently more streams, to a file. As the file’s data is itself an attribute of the file and because new attributes can be added, NTFS files, and file directories, can contain multiple data streams.
An NTFS attribute has one default data stream, which has no name (unnamed). An application can create additional named data streams and access them by referring to their names. To avoid problems, the name of the data stream is specified by appending a colon ( : ) to the filename. Because the colon is a reserved character, it can serve as a separator between the filename and the data stream name.
Each stream has a separate allocation size, which defines how much space has been reserved for it; actual size, which is how many bytes the caller has used; valid data length, which is how much of the stream has been initialised. In addition, each stream is given a separate file lock that is used to lock byte ranges and to allow concurrent access.
An example of an application that uses streams is Windows Explorer. Right-clicking on an NTFS file and selecting Properties, the Summary tab of the resulting dialog box allows the user to associate information with the file, such as title, subject, author, and keywords. Windows Explorer stores the information in an alternative stream (alternative data stream (ADS), NTFS alternative stream or named stream) it adds to the file, named Summary Information. Typically, backup programs will copy the main stream only and ignore all the alternative streams. However, Genie Backup Manager Home, Professional and Server will use the extra data stream to store backup-specific timestamps on files. Moreover, Genie’s Backup programs implement hierarchical storage in which files that are older than a certain date or have not been accessed for a specified period of time are moved to an archive backup medium, such as tape.
See: Attribute and File Attribute.

Multi-Partition Volumes

Objects that represent sectors from multiple partitions that the filesystem drivers manage as a single unit. Multi-partitions volumes offer performance, reliability, and sizing features that simple volumes do not.
See: Dynamic Volume (Simple (volume set in NT4)), Partition, and Volume.

Multi-Path I/O (MPIO) Drivers

Typically disk devices have one path-or series of adapters, cables, and switches between them and a computer. Servers require high levels of availability by using multi-pathing solutions, where more than one set of connection hardware exists between the computer and a disk so that if a path fails the system can still access the disk though an alternative path. Without support of the operating system or disk drivers, however, a disk with two paths, for example, appears as two different disks. Windows includes multi-path I/O support to manage multi-path disks as a single disk that relies on third-party drivers called device-specific modules (DSMs) to manage details of the path management, such as load balancing policies that choose which path to route requests and error detection mechanisms to inform Windows when a path fails. MPIO support is available for Windows 2000 Server, Advanced Server, DataCenter and Windows Server 2003.
See: Multi-Pathing.

Multi-Pathing

Where more than one set of hardware exists between the computer and a disk so that if one path fails the system can still access the disk via an alternative route or path.
See: Multi-Path I/O (MPIO) Drivers.