Journaling NTFS is a
journaling file system and uses the NTFS Log () to record metadata changes to the volume. It is a feature that FAT does not provide and is 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. The () format has evolved through several versions: The incompatibility of the versions implemented by
Windows 8,
Windows 10,
Windows 11 prevents
Windows 7 (and earlier versions of Windows) from recognizing version 2.0 of the . Backward compatibility is provided by downgrading the to version 1.1 when an NTFS volume is cleanly dismounted. It is again upgraded to version 2.0 when mounting on a compatible version of Windows. However, when hibernating to disk in the logoff state (a.k.a. Hybrid Boot or Fast Boot, which is enabled by default), mounted file systems are not dismounted, and thus the s of any active file systems are not downgraded to version 1.1. The inability to process version 2.0 of the by versions of Windows older than 8.0 results in an unnecessary invocation of the
CHKDSK disk repair utility. This is particularly a concern in a
multi-boot scenario involving pre- and post-8.0 versions of Windows, or when frequently moving a storage device between older and newer versions. A
Windows Registry setting exists to prevent the automatic upgrade of the to the newer version. The problem can also be dealt with by disabling Hybrid Boot. The
USN Journal (Update Sequence Number Journal) is a system management feature that records (in ) 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.
Hard links The
hard link feature allows different file names to directly refer to the same file contents. Hard links may link only to files in the same volume, because each volume has its own
MFT. Hard links were originally included to support the
POSIX subsystem in Windows NT. Although hard links use the same MFT record (
inode) which records file metadata such as file size, modification date, and attributes, NTFS also caches this data in the directory entry as a performance enhancement. This means that when listing the contents of a directory using FindFirstFile/FindNextFile family of APIs, (equivalent to the POSIX opendir/readdir APIs) the software listing the directory will also receive this cached information, in addition to the name and inode. However, software may not see up-to-date information, as this information is only guaranteed to be updated when a file is closed, and then only for the directory from which the file was opened. This means where a file has multiple names via hard links, updating a file via one name does not update the cached data associated with the other name. Software can obtain up-to-date data using GetFileInformationByHandle (which is the equivalent of the POSIX fstat function). This can be done using a handle which has no access to the file itself (passing zero to CreateFile for dwDesiredAccess), and closing this handle has the incidental effect of updating the cached information. 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, but support can be disabled. 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 hard link. The NTFS file system has a limit of 1023
hard links on a file.
Alternate data stream (ADS) 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"). These streams are not shown to or made editable by users through any typical
GUI application built into Windows by default, disguising their existence from most users. Although intended for helpful
metadata, their arcane nature makes them a potential hiding place for malware, spyware, unseen browser history, and other potentially unwanted information. 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 cause problems. Microsoft provides a downloadable 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. A small ADS named Zone.Identifier is added by
Internet Explorer and by most 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. This functionality is also known as "
Mark of the Web". All
Chromium (e.g.
Google Chrome) and
Firefox-based web browsers also write the Zone.Identifier stream to downloaded files.
Malware has used alternate data streams to hide code. Since the late 2000s, some malware scanners and other special tools check for alternate data streams. Due to the risks associated with ADS, particularly involving privacy and the Zone.Identifier stream, there exists software specifically designed to strip streams from files (certain streams with perceived risk or all of them) in a user-friendly way. 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.
File compression Compression is enabled on a per-folder or per-file basis by setting the 'compressed' attribute. When compression is enabled on a folder, any files moved or saved to that folder will be automatically
compressed using LZNT1 algorithm (a variant of
LZ77). The compression algorithm is 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. Data is compressed in 16-cluster chunks (up to 64 KB in size); if the compression reduces 64KB of data to 60KB or less, NTFS treats the unneeded 4KB pages like empty
sparse file clusters—they are not written. This allows for reasonable random-access times as the OS merely has to follow the chain of fragments. Compression works best with files that have repetitive content, are seldom written, are usually accessed sequentially, and are not themselves compressed. Single-user systems with limited hard disk space can benefit from NTFS compression for small files, from 4KB to 64KB or more, depending on compressibility. Files smaller than approximately 900 bytes are stored within the directory entry of the
MFT. Various programs utilize NTFS file compression, such as
CompactGUI.
Advantages 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. Even when SSD controllers already compress data, there is still a reduction in I/Os since less data is transferred. According to research by Microsoft's NTFS Development team, 50–60
GB is a reasonable maximum size for a compressed file on an NTFS volume with a 4KB (default) cluster (block) size. This reasonable maximum size decreases sharply for volumes with smaller cluster sizes. Flash memory, such as
SSD drives do not have the head movement delays and high
access time of mechanical
hard disk drives, so fragmentation has only a smaller penalty.
Windows 2000 cannot start if
NTLDR is compressed because decompression filters are not yet loaded. Later versions of Windows do not allow important system files to be compressed.
System compression Since
Windows 10, Microsoft has introduced new file compression scheme based on the XPRESS algorithm with 4K/8K/16K block size and the
LZX algorithm; both are variants of
LZ77 updated with
Huffman entropy coding and
range coding, which LZNT1 lacked. These compression algorithms were taken from
Windows Imaging Format (WIM file). The new compression scheme is used by CompactOS feature, which reduces disk usage by compressing Windows system files. CompactOS is not an extension of NTFS file compression and does not use the 'compressed' attribute; instead, it sets a
reparse point on each compressed file with a WOF (Windows Overlay Filter) tag, but the actual data is stored in an alternate data stream named "WofCompressedData", which is decompressed on-the-fly by a WOF
filesystem filter driver, and the main file is an empty
sparse file. CompactOS compression is intended for
OEMs who prepare OS images with the flag of the
tool in
Windows ADK, but it can also be manually turned on per file with the flag of the command. CompactOS algorithm avoids
file fragmentation by writing compressed data in contiguously allocated chunks, unlike core NTFS compression. CompactOS file compression is an improved version of WIMBoot feature introduced in
Windows 8.1. WIMBoot reduces Windows disk usage by keeping system files in a
compressed WIM image on a separate hidden
disk partition. Similarly to CompactOS, Windows system directories only contain
sparse files marked by a reparse point with a WOF tag, and Windows Overlay Filter driver decompresses file contents on-the-fly from the WIM image. WIMBoot is less effective than CompactOS though, as new updated versions of system files need to be written to the system partition, consuming disk space. A sparse file does not necessarily include sparse zeros areas; the "sparse file" attribute just means that the file is allowed to have them. 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 The
Volume 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. 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 that NTFS volume. This happens because the older operating system does not understand the newer format of persistent shadow copies. 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 participants). 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: "Microsoft strongly recommends developers utilize alternative means" since "TxF may not be available in future versions of Microsoft Windows".
Quotas 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 to them.
Reparse points Introduced in NTFS v3, NTFS reparse points are used by associating a reparse tag in the user space attribute of a file or directory. Microsoft includes several default tags including
symbolic links,
directory junction points and
volume mount points. When the
Object Manager 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 request and performs its special functionality.
Date and time NTFS stores date and time attributes as a 64-bit integer that counts the 100-nanosecond intervals from the beginning of the year 1601, following the Windows NT epoch. The year 1601 was chosen to align the beginning of the date range with the
gregorian calendar in order to simplify calculations, given that the gregorian calendar operates on a 400-year cycle, and the 1601-2000 cycle was the active cycle at the time Windows NT was conceived. NTFS records four types of time stamps: A file creation time (interpreted as "birth time" on Linux), a last modification time, a last modification of the MFT record (interpreted as "change time" on Linux) and a last access time. Each of those times has the same granularity of 100 nanoseconds. == Limitations ==