View source for NTFS

{{lead too short|date=February 2014}}
{{infobox file system
| name                    = NTFS
| full_name               = New Technology File System<ref name="ntfs_abbr" />
| developer               = [[Microsoft]]
| introduction_os         = [[Windows NT 3.1]]
| introduction_date       = July 1993
| partition_id            = <tt>[[Partition type#PID 07h|0x07]]</tt> ([[Master boot record|MBR]]) <br /> <tt>[[Basic Data Partition|EBD0A0A2-B9E5-4433-87C0-68B6B72699C7]]</tt> ([[GUID Partition Table|GPT]])
| directory_struct        = [[B+ tree]]<ref name=insidewin2kntfs>{{cite web | url = https://msdn2.microsoft.com/en-us/library/ms995846.aspx | title = Inside Win2K NTFS, Part 1 | first = Mark |last=Russinovich | website = [[MSDN|Microsoft Developer Network]] |publisher=[[Microsoft]] | accessdate = 2008-04-18 | authorlink = Mark Russinovich }}</ref>
| file_struct             = Bitmap
| bad_blocks_struct       = $BadClus (MFT Record)
| max_filename_size       = 255 [[UTF-16]] code units<ref name="ntfsdoc">{{cite web | url = https://dubeyko.com/development/FileSystems/NTFS/ntfsdoc.pdf | title = NTFS Documentation | first1 = Richard |last1 = Russon |first2 = Yuval |last2 = Fledel | accessdate = 2011-06-26 }}</ref>
| max_files_no            = 4,294,967,295 (2<sup>32</sup>-1)<ref name="How NTFS Works">{{cite web | url = https://technet.microsoft.com/en-us/library/cc781134(v=ws.10).aspx | title = How NTFS Works | date = 2003-03-28 | work = Windows Server 2003 Technical Reference | accessdate = 2011-09-12 }}</ref>
| max_file_size           = 16&nbsp;[[exbibyte|EiB]]&nbsp;– 1&nbsp;[[kibibyte|KiB]] (format);<br />16&nbsp;[[tebibyte|TiB]]&nbsp;– 64&nbsp;[[kibibyte|KiB]] ([[Windows 7]], [[Windows Server 2008 R2]] or earlier implementation)<ref name="How NTFS Works"/> 256&nbsp;[[tebibyte|TiB]]&nbsp;– 64&nbsp;[[kibibyte|KiB]] ([[Windows 8]], [[Windows Server 2012]] implementation)<ref name="MS-FSA">{{cite web | url = https://msdn.microsoft.com/en-us/library/ff469400%28v=prot.20%29.aspx#id116 | title = 6 Appendix A: Product Behavior | work = [MS-FSA]: File System Algorithms | publisher = Microsoft | date = 14 November 2013 | accessdate = 2012-09-21 }}</ref>
| max_volume_size         = 2<sup>64</sup> [[Data cluster|clusters]] − 1 cluster (format);<br />256&nbsp;[[tebibyte|TiB]] − 64&nbsp;[[kibibyte|KiB]] (implementation)<ref name="How NTFS Works"/>
| filename_character_set  = In [[POSIX]] namespace, any [[UTF-16]] code unit (case-sensitive) except {{nowrap|U+0000 ([[null character|NUL]])}} and {{nowrap|/ ([[slash (punctuation)|slash]])}}. In Win32 namespace, any [[UTF-16]] code unit (case-insensitive) except {{nowrap|U+0000 ([[null character|NUL]])}} {{nowrap|/ ([[slash (punctuation)|slash]])}} {{nowrap|\ ([[backslash]])}} {{nowrap|: ([[colon (punctuation)|colon]])}} {{nowrap|* ([[asterisk]])}} {{nowrap|? ([[Question mark]])}} {{nowrap|" ([[Quotation mark|quote]])}} {{nowrap|< ([[Bracket|less than]])}} {{nowrap|> ([[Bracket|greater than]])}} and {{nowrap|&#124; ([[Vertical bar|pipe]])}} <ref name="ntfsdoc"/>
| dates_recorded          = Creation, modification, POSIX change, access
| date_range              = 1 January 1601&nbsp;– 28 May 60056 (File times are 64-bit numbers counting 100-nanosecond intervals (ten million per second) since 1601, which is 58,000+ years)
| date_resolution         = 100&nbsp;ns
| forks_streams           = Yes (see [[#Alternate data streams (ADS)|§ Alternate data streams]] below)
| attributes              = Read-only, hidden, system, archive, not content indexed, off-line, temporary, compressed
| file_system_permissions = [[Access Control List|ACLs]]
| compression             = Per-file, [[LZ77]] ([[Windows NT 3.51]] onward)
| single_instance_storage = Yes ([[Windows Server 2012]])<ref name="singleinstancestorage">{{cite web | url = https://www.techrepublic.com/blog/datacenter/windows-server-8-data-deduplication-what-you-need-to-know/4887 | title = Windows Server 8 data deduplication | author = Rick Vanover | accessdate = 2011-12-02 }}</ref>
| encryption              = Per-file,<br />[[DESX]] ([[Windows 2000]] onward),<br />[[Triple DES]] ([[Windows XP]] onward),<br />[[Advanced Encryption Standard|AES]] (Windows XP Service Pack 1, [[Windows Server 2003]] onward)
| OS                      = [[Windows NT 3.1]] and later<br/>[[OS X 10.3]] and later (read-only)<br />many [[Linux distribution|Linux distributions]]
}}

'''NTFS''' ('''New Technology File System'''<ref name="ntfs_abbr" />) is a [[Proprietary software|proprietary]] [[file system]] developed by [[Microsoft]].<ref name="ntfs_abbr">{{cite web | url=https://msdn.microsoft.com/en-us/library/cc230448.aspx | title=1.1 Glossary | work=[MS-EFSR]: Encrypting File System Remote (EFSRPC) Protocol | publisher=Microsoft | date=14 November 2013 }}</ref> Starting with [[Windows NT 3.1]], it is the default file system of [[Windows NT]] family.<ref name="Custer, Helen">{{cite book | last=Custer | first=Helen | title=Inside the Windows NT File System | year=1994 | publisher=[[Microsoft Press]] | isbn=978-1-55615-660-1 }}</ref>

NTFS has several technical improvements over [[File Allocation Table|FAT]] and HPFS ([[High Performance File System]]), the file systems that it superseded, such as improved support for [[metadata (computing)|metadata]], and the use of advanced data structures to improve performance, reliability, and disk space utilization, plus additional extensions, such as security [[access control list]]s (ACL) and [[journaling file system|file system journaling]].

== History ==

In the mid-1980s, Microsoft and [[IBM]] formed a joint project to create the next generation of graphical [[operating system]]. The result of the project was [[OS/2]], but Microsoft and IBM disagreed on many important issues and eventually separated: OS/2 remained an IBM project and Microsoft worked on Windows NT. 

The OS/2 file system [[High Performance File System|HPFS]] contained several important new features. When Microsoft created their new operating system, they borrowed many of these concepts for NTFS.<ref>{{ cite web | url=https://www.pcguide.com/ref/hdd/file/ntfs/over-c.html | title=Overview and History of NTFS | last=Kozierok | first=Charles M. | date=April 17, 2001 | publisher=PCGuide }}</ref> Probably as a result of this common ancestry, HPFS and NTFS use the same [[disk partitioning|disk partition]] identification type code (07).

Using the same Partition ID Record Number is unusual, since there were dozens of available codes, and other major file systems have their own code. 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.

== Developers ==

NTFS developers include:<ref>{{ cite book |last= Custer |first= Helen |title= Inside the Windows NT File System |year= 1994 | publisher= [[Microsoft Press]] |isbn= 978-1-55615-660-1 |page=vii}}</ref>
* [[Tom Miller (computer programmer)|Tom Miller]]
* [[Gary Kimura]]
* Brian Andrew
* David Goebel

== Versions ==

Microsoft has released five versions of NTFS:

* '''v1.0''': Released with [[Windows NT 3.1]] in 1993.<ref name="Custer, Helen" /> v1.0 is incompatible with v1.1 and newer: Volumes written by Windows NT 3.5x cannot be read by Windows NT 3.1 until an update (available on the NT 3.5x installation media) is installed.<ref>{{ cite web | url=https://support.microsoft.com/kb/q129102/ | title=Recovering Windows NT After a Boot Failure on an NTFS Drive | publisher=Microsoft | date=November 1, 2006 }}</ref>
* '''v1.2''': Released with [[Windows NT 3.51]] in 1995. Supports compressed files, named streams and [[access control list]]s<ref name="insidewin2kntfs" />
* '''v3.0''': Released with [[Windows 2000]].<ref name="Inside Win2K NTFS, Part 1">{{cite web | url=https://msdn.microsoft.com/en-us/library/ms995846.aspx | title=Inside Win2K NTFS, Part 1 | publisher=Microsoft | date=January 26, 2011 }}</ref> Supports disk quotas, [[Encrypting File System]], [[sparse file]]s, reparse points, update sequence number (USN) journaling, the $Extend folder and its files. Reorganized [[security descriptor]]s so that multiple files using the same security setting can share the same descriptor.<ref name=insidewin2kntfs />
* '''v3.1''': Released with [[Windows XP]] in Autumn, 2001 (and subsequently used also for Windows Vista and Windows 7). Expanded the [[#Master File Table|Master File Table]] (MFT) entries with redundant MFT record number (useful for recovering damaged MFT files).

The NTFS.sys version number (e.g. v5.0 in Windows 2000) should not be confused with the NTFS format version number (v3.1 since Windows XP).<ref>{{ cite web | url=https://support.microsoft.com/kb/310749 | title=New Capabilities and Features of the NTFS 3.1 File System | publisher=Microsoft | date=December 1, 2007 }}</ref>

Although subsequent versions of Windows added new file system-related features, they did not change NTFS itself. For example, [[Windows Vista]] implemented [[NTFS symbolic link]]s, [[Transactional NTFS]], partition shrinking and self-healing.<ref>{{ cite web |url=https://download.microsoft.com/download/5/b/9/5b97017b-e28a-4bae-ba48-174cf47d23cd/STO123_WH06.ppt |title=Storage improvements in Windows Vista and Windows Server 2008 |publisher=Microsoft |accessdate=2007-09-04 |format=PowerPoint |pages=14–20 |last=Loveall |first=John |year=2006}}</ref> All except NTFS symbolic links are operating system's features.

== Features ==

NTFS v3.0 includes several new features over its predecessors: sparse file support, disk usage quotas, reparse points, distributed link tracking, and file-level encryption, also known as the [[Encrypting File System]] (EFS).

=== Scalability ===

In theory, the maximum NTFS volume size is 2<sup>64</sup>−1 clusters. However, the maximum NTFS volume size as implemented in Windows XP Professional is 2<sup>32</sup>−1 clusters partly due to partition table limitations. For example, using 64 kB clusters, the maximum Windows XP NTFS volume size is 256 [[tebibyte|TB]] minus 64 [[kibibyte|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 [[gibibyte|GB]] limit lifted in [[Windows XP#Service Pack 1|Windows XP SP1]].) Because partition tables on master boot record (MBR) disks only support partition sizes up to 2 TB, dynamic or [[GUID Partition Table|GPT]] volumes must be used to create NTFS volumes over 2 TB. Booting from a GPT volume to a Windows environment in a Microsoft supported way requires a system with [[Unified Extensible Firmware Interface|UEFI]] and 64-bit support.<ref>https://www.rodsbooks.com/gdisk/booting.html</ref>

The maximum theoretical file size on NTFS is 16&nbsp;[[exabyte|EB]] ({{nowrap|16 × 1024<sup>6</sup> or 2<sup>64</sup> bytes}}) minus 1 kB or 18,446,744,073,709,550,592 bytes. With [[Windows 8]] and [[Windows Server 2012]], the maximum file size implemented is 256 TB minus 64 KB or 281,474,976,645,120 bytes.<ref name="MS-FSA" />

NTFS supports a maximum cluster size of 64 kB.<ref>{{ cite web | url = https://msdn.microsoft.com/en-us/library/ff469400%28v=prot.20%29.aspx#id2 | title = &#x5b;MS-FSA&#x5d;: File System Algorithms. Appendix A: Product Behavior | publisher = Microsoft | accessdate = 2012-01-10 }}</ref>

=== Journaling ===

NTFS is a [[journaling file system]] and uses the NTFS Log ($LogFile) to record metadata changes to the volume. It is a critical functionality of NTFS (a feature that FAT/FAT32 does not provide) for ensuring that its internal complex data structures (notably the volume allocation bitmap), or data moves performed by the [[defragmentation]] API, the modifications to [[#Master File Table|MFT]] records (such as moves of some variable-length attributes stored in MFT records and attribute lists), and indices (for directories and [[security descriptor]]s) will remain consistent in case of system crashes, and allow easy rollback of uncommitted changes to these critical data structures when the volume is remounted.

The [[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.<ref>{{ cite web|url=https://msdn.microsoft.com/en-us/library/aa363798.aspx|title=Change Journals (Windows)|publisher=[[MSDN]]|accessdate=2010-04-16}}</ref> This journal can be enabled or disabled on non-system volumes.<ref>{{ cite web|url=https://msdn.microsoft.com/en-us/library/aa363877(v=VS.85).aspx|title=Creating, Modifying, and Deleting a Change Journal (Windows)|publisher=[[MSDN]]|accessdate=2010-04-16}}</ref>

=== Hard links ===

Hard links allows different file names to refer to the same file contents.

[[Hard link]]s are similar to [[NTFS#Reparse points|directory junctions]], but refer to files instead. Hard links may link to files in the same volume only because each volume has its own [[#Master File Table|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.<ref>{{ cite web|title=Hard Links and Junctions|url=https://msdn.microsoft.com/en-us/library/aa365006%28VS.85%29.aspx|work=[[MSDN]]|publisher=[[Microsoft]]|accessdate=21 October 2013|date=12 October 2013}}</ref>

Hard links were originally included to support the [[POSIX]] subsystem in Windows NT.<ref>{{ cite web|title=Chapter 29 - POSIX Compatibility|url=https://technet.microsoft.com/en-us/library/cc768080.aspx|work=MS Windows NT Workstation 4.0 Resource Guide|publisher=[[Microsoft]]|accessdate=21 October 2013|year=1995}}</ref>

Windows uses hard links to support [[8.3 filename|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 hard link.

=== Alternate data streams (ADS) ===

[[Fork (filesystem)|Alternate data streams]] allow more than one data stream to be associated with a filename, 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 fork]]s. 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 (called 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.<ref>{{ cite book | title = Windows Internals | edition = 5th | last1 = Russinovich | first1 = Mark E. | authorlink = Mark Russinovich | last2 = Solomon | first2 = David A. | last3 = Ionescu | first3 = Alex | publisher = Microsoft Press | year = 2009 | chapter = File Systems | page = 921 | quote = 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 | ISBN = 978-0-7356-2530-3 }}</ref> 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. They are ignored when the file is copied or moved to another file system without ADS support, attached to an e-mail, or uploaded to a website. Thus, using alternate streams for critical data may cause problems. Microsoft provides a tool called Streams<ref>[https://technet.microsoft.com/en-us/sysinternals/bb897440.aspx Sysinternals Streams v1.56]</ref> to view streams on a selected volume. Starting with [[Windows PowerShell]] 3.0, it is possible to manage ADS natively with seven cmdlets: Add-Content, Clear-Content, Get-Content, Get-Item, Out-String, Remove-Item, Set-Content.<ref>{{cite web|title=FileSystem Provider|url=https://technet.microsoft.com/en-us/library/hh847764(v=wps.620).aspx|publisher=Microsoft|accessdate=23 January 2015|date=9 August 2012}}</ref>

[[Malware]] has used alternate data streams to hide code.<ref>[https://www.auscert.org.au/render.html?it=7967 Malware utilising Alternate Data Streams?], AusCERT Web Log, 21 August 2007</ref> As a result, malware scanners and other special tools now check for alternate data streams.

=== File compression ===

NTFS can [[data compression|compress]] files using LZNT1 algorithm (a variant of the [[LZ77]]<ref>{{ cite web | url=https://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/file_compression_and_decompression.asp | title=File Compression and Decompression | publisher=MSDN Platform SDK: File Systems | accessdate=2005-08-18}}</ref>). Files are compressed in 16-cluster chunks. With 4&nbsp;kB clusters, files are compressed in 64&nbsp;kB chunks. The compression algorithms in 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.<ref>{{ cite web | url = https://support.microsoft.com/kb/314878 | title = The Default Cluster Size for the NTFS and FAT File Systems | publisher = Microsoft | date = January 31, 2002 | accessdate = 2012-01-10 }}</ref> If the compression reduces 64&nbsp;kB of data to 60&nbsp;kB or less, NTFS treats the unneeded 4&nbsp;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 < 64KB becomes a fragment.<ref>{{ cite web | url=https://blogs.msdn.com/b/ntdebugging/archive/2008/05/20/understanding-ntfs-compression.aspx | title=Understanding NTFS Compression | accessdate=2011-03-16}}</ref><ref>{{ cite web|url=https://www.forensicfocus.com/index.php?name=Content&pid=179|title=Shrinking the gap: carving NTFS-compressed files|accessdate=2011-05-29}}</ref> Single-user systems with limited hard disk space can benefit from NTFS compression for small files, from 4&nbsp;kB to 64&nbsp;kB or more, depending on compressibility. Files less than 900 bytes or so are stored within the directory entry at the [[#Master File Table|MFT]].<ref>{{cite web | url=https://technet.microsoft.com/en-us/library/cc781134%28WS.10%29.aspx | title=How NTFS Works | date=2003-03-28 | accessdate= 2011-10-24}}</ref>

Flash memory, such as [[SSD]] drives do not have the head movement delays of [[hard disk drives]], so fragmentation has only small effects. Users of fast [[multi-core processor]]s will find improvements in application speed by compressing their applications and data as well as a reduction in space used.<ref>{{cite web | url=https://www.tomshardware.com/reviews/ssd-ntfs-compression,3073-11.html | title=Should You Compress Data On Your SSD? | work=Tom's Hardware | publisher=Bestofmedia Group | first=Manuel | last=Masiero | date=2011-12-01 | accessdate = 2013-04-05 }}</ref> Note that SSDs with Sandforce controllers already compress data. However, since less data is transferred, there is a reduction in I/Os.

The best use of compression is for files that are repetitive, seldom written, usually accessed sequentially, and not themselves compressed. Log files are an ideal example.

Compressing system files needed at boot time, like drivers, NTLDR, winload.exe, or BOOTMGR may prevent the system from booting correctly, as compression filters are not available then.<ref>{{cite web | url=https://technet.microsoft.com/en-us/library/cc977213.aspx | title=Disk Concepts and Troubleshooting | publisher=Microsoft | accessdate=2012-03-26}}</ref> However, in later editions of Windows, compression of important system files is disallowed.

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<ref>{{cite web | url=https://msdn.microsoft.com/en-us/library/ms190257.aspx | title=Read-Only Filegroups and Compression | work=SQL Server 2008 Books Online |publisher=[[Microsoft]] |date=November 2009 | accessdate=2010-04-20}}</ref> [[Network transparency|transparent]], Microsoft recommends avoiding compression on server systems and/or network shares holding roaming profiles because it puts a considerable load on the processor.<ref>"[https://support.microsoft.com/default.aspx?scid=kb;en-us;Q251186 Best practices for NTFS compression in Windows]." ''Microsoft Knowledge Base.'' Retrieved on 2005-08-18.</ref> Since many fragments are created for compressible files, [[defragmentation]] may take longer.

=== Sparse files ===

[[File:Sparse file (en).svg|thumb|A sparse file: Empty bytes don't need to be saved, thus they can be represented by [[metadata]].]]

[[Sparse file]]s 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 zeros.<ref>{{ cite web|title=Sparse Files|url=https://msdn.microsoft.com/en-us/library/windows/desktop/aa365564%28v=vs.85%29.aspx|work=[[MSDN]]|publisher=[[Microsoft]]|accessdate=21 October 2013|date=12 October 2013}}</ref>

Database applications, for instance, may use sparse files.<ref>{{ cite web|last=Kandoth|first=Suresh B.|title=Sparse File Errors: 1450 or 665 due to file fragmentation: Fixes and Workarounds|url=https://blogs.msdn.com/b/psssql/archive/2009/03/04/sparse-file-errors-1450-or-665-due-to-file-fragmentation-fixes-and-workarounds.aspx|work=CSS SQL Server Engineers|publisher=[[Microsoft]]|accessdate=21 October 2013|date=4 March 2009}}</ref> As with compressed files, the actual sizes of sparse files are not taken into account when determining quota limits.<ref>{{ cite web|title=Sparse Files and Disk Quotas|url=https://msdn.microsoft.com/en-us/library/aa365565.aspx|work=[[MSDN Library]]|publisher=[[Microsoft]]|accessdate=21 October 2013|date=12 October 2013}}</ref>

=== Volume Shadow Copy ===

The [[Shadow Copy|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. On heavily loaded systems, Microsoft recommends setting up a shadow copy volume on a separate disk.<ref>{{ cite web | url=https://technet.microsoft.com/en-us/library/cc728305.aspx | title=Designing a Shadow Copy Strategy | work=[[Microsoft TechNet#Library|TechNet Library]] |publisher=[[Microsoft]] | accessdate=2008-01-15 |date=28 March 2003}}</ref>

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.<ref>{{cite web |url=https://blogs.technet.com/filecab/archive/2006/07/14/441829.aspx | title=How restore points and other recovery features in Windows Vista are affected when you dual-boot with Windows XP | author=cfsbloggers | date=July 14, 2006 | work=The Filing Cabinet | accessdate=2007-03-21 }}</ref>

=== Transactions ===

As of Windows Vista, applications can use [[Transactional NTFS]] (TxF) to group changes to files together into a transaction. The transaction will guarantee that all changes happen, or none of them do, and it will guarantee that applications outside the transaction will not see the changes until they are committed.<ref>{{ cite web|url=https://msdn2.microsoft.com/en-us/library/aa363764.aspx|title=Transactional NTFS|work=[[MSDN]]|publisher=[[Microsoft]]|accessdate=2007-02-02}}</ref>

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 [[Common Log File System|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 [[Distributed Transaction Coordinator|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 filesystems, including with their local live or offline caches.

Microsoft now advise against using TxF: "Microsoft strongly recommends developers utilize alternative means..." since "TxF may not be available in future versions of Microsoft Windows"<ref name=NTFS-TxF>{{cite web|title=Transactional NTFS (TxF)|url=https://msdn.microsoft.com/en-us/library/windows/desktop/bb968806(v=vs.85).aspx|website=Windows Dev Center (MSDN)|publisher=Microsoft|accessdate=24 May 2015|ref=42}}</ref>

=== Security ===

In NTFS, each file or folder is assigned a [[security descriptor]] that defines its owner and contains two [[Access control list|access control lists]] (ACLs). The first ACL, called [[discretionary access control]] list (DACL), defines exactly what type of interaction (e.g. reading, writing, executing or deleting) is allowed or forbidden by which user or groups of users. For example, files in C:\Program Files folder may be read and executed by all users but only modified by a user holding administrative privileges.<ref name=":0">{{Cite web|url = https://technet.microsoft.com/en-us/library/cc781716%28v=ws.10%29.aspx|title = How Security Descriptors and Access Control Lists Work|date = |accessdate = 4 September 2015|website = [[Microsoft TechNet|TechNet]]|publisher = [[Microsoft]]|last = |first = }}</ref> Windows Vista adds [[mandatory access control]] info to DACLs. DACLs are the primary focus of [[User Account Control]] in Windows Vista and later. 

The second ACL, called system access control list (SACL), defines what interactions with the file or folder is 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.<ref name=":0" />

=== Encryption ===

{{Main|Encrypting File System}}

[[Encrypting File System]] (EFS) provides strong<ref>{{ cite web | url=https://technet.microsoft.com/en-us/magazine/2007.02.securitywatch.aspx | title=Security Watch Deploying EFS: Part 1 | first=John | last=Morello | work=Technet Magazine | publisher=[[Microsoft]] | date=February 2007 | accessdate=2009-01-25 }}</ref> and user-transparent encryption of any file or folder on an NTFS volume. EFS works in conjunction with the EFS service, Microsoft's [[Cryptographic Application Programming Interface|CryptoAPI]] and the EFS File System Run-Time Library (FSRTL). EFS works by encrypting a file with a bulk [[symmetric key algorithm|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 algorithm|asymmetric key]] cipher is used. The symmetric key that is used to encrypt the file is then encrypted with a [[public key cryptography|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.<ref>{{cite web|title=How EFS Works|url=https://technet.microsoft.com/library/Cc962103|work=Windows 2000 Resource Kit|publisher=[[Microsoft]]|accessdate=25 February 2014}}</ref> 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.

=== Quotas ===

[[Disk quota]]s 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 ===

{{Main|NTFS reparse point}}

[[NTFS reparse point]]s, 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 link]]s, [[NTFS junction point|directory junction points]] and [[NTFS volume mount point|volume mount points]]. When the object manager (see [[Architecture of the Windows NT operating system line#Executive|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 functionality.

=== Resizing ===

Starting with [[Windows Vista]] Microsoft added the built-in ability to shrink or expand a partition, but this capability is limited because it will not relocate page file fragments or files that have been marked as unmovable. So shrinking will often require relocating or disabling any [[Pagefile#Windows NT|page file]], the index of [[Windows Search]], and any [[#Volume Shadow Copy|Shadow Copy]] used by [[System Restore]]. Various third-party tools are capable of resizing NTFS partitions.

== Internals ==

[[File:NTPermissions.png|thumb|right|150px|NTFS filesystem permissions on a [[Windows Vista]] system]]

Internally, NTFS uses [[B+ tree]]s to index file system data. Although complex to implement, this allows faster file look up times in most cases. 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://technet.microsoft.com/library/cc750355.aspx|work=MS Windows NT Workstation 4.0 Resource Guide|publisher=[[Microsoft]]|accessdate=25 February 2014}}</ref>

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/UCS-2|UTF-16]] (it allows any sequence of short values, not restricted to those in the Unicode standard). 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>$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"/> (dot) and $Extend 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://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx#naming_conventions|work=[[MSDN]]|publisher=[[Microsoft]]|accessdate=25 February 2014|at=Naming Conventions}}</ref>

=== {{Anchor|PBS}} Partition Boot Sector ===

{| class="wikitable sortable"
|+ NTFS Boot Sector contents
! Byte Offset !! Field length !! Typical Value !! Field Name !! Purpose
|-
| 0x00 
| 3 bytes
| 0xEB5290
| JMP instruction
| Causes execution to continue after the data structures in this boot sector.
|-
| 0x03
| 8 bytes
| "<code>NTFS&ensp;&ensp;&ensp;&ensp;</code>"<br /><small>Word "NTFS" followed by four trailing spaces (0x20)</small>
| OEM ID
| This is the magic cookie that indicates this is an NTFS filesystem.
|-
| 0x0B 	
| 2 bytes
| 0x0200
| Bytes per sector
| How many bytes are in a sector?
|-
| 0x0D 	
| 1 byte
| 0x08
| Sectors Per Cluster
| How many sectors are in a cluster?
|- 
| 0x0E 	
| 2 bytes
| 0x0000
| Reserved Sectors
| How much space is reserved by the OS.  Not specified as to where in the reference cited.
|-
| 0x10 	
| 3 bytes
| 0x000000
| Unused
| This field is always 0
|-
| 0x13
| 2 bytes
| 0x0000
| Unused by NTFS
| This field is always 0
|-
| 0x15 	
| 1 byte
| 0xF8
| Media Descriptor
| Not specified in reference cited.
|-
| 0x16 	
| 2 bytes
| 0x0000
| Unused
| This field is always 0
|-
| 0x18 	
| 2 bytes
| 0x003F
| Sectors Per Track
| How many sectors are there per track?
|-
| 0x1A 	
| 2 bytes
| 0x00FF
| Number Of Heads
| How many magnetic read-write heads are there in this drive?
|-
| 0x1C 	
| 4 bytes
| 0x0000003F
| Hidden Sectors
| How many hidden sectors are there?  Location not specified in reference cited.
|-
| 0x20 	
| 4 bytes
| 0x00000000
| Unused
| Not used by NTFS
|-
| 0x24 	
| 4 bytes
| 0x80008000
| Unused
| Not used by NTFS
|-
| 0x28 	
| 8 bytes
| 0x00000000007FF54A
| Total sectors	
| How many sectors are in this partition?  
|-
| 0x30 	
| 8 bytes
| 0x0000000000000004
| $MFT cluster number
| Which cluster contains the $MFT?
|-
| 0x38 	
| 8 bytes
| 0x000000000007FF54
| $MFTMirr cluster number
| Which cluster contains the mirror (backup) $MFT
|-
| 0x40 	
| 1 byte
| 0xF6
| Bytes Per File Record Segment
| How many bytes per file record segment? If negative then value is 2 to the power of -value, e.g. if value is 0xF6 then record length is 2^10 (10==-0xf6)
|-
| 0x44 	
| 1 byte
| 0x01
| Clusters Per Index Buffer
| How many clusters per index buffer? Algorithm as for bytes per record above
|-
| 0x45 	
| 3 bytes
| 0x000000
| Unused
| This field is not used by NTFS
|-
| 0x48 	
| 8 bytes
| 0x1C741BC9741BA514
| Volume Serial Number
| A unique random number assigned to this partition, to keep things organized.
|-
| 0x50 	
| 4 bytes
| 0x00000000
| Checksum
| A checksum of the previous values.  Algorithm not described in cited article.
|-
| 0x54 	
| 426 bytes
| 
| Bootstrap Code
| The code that loads the rest of the operating system.  This is pointed to by the first 3 bytes of this sector.
|-
| 0x01FE 	
| 2 bytes
| 0xAA55
| End-of-sector Marker
| This flag indicates that this is a valid boot sector.
|}
<ref>[https://www.ntfs.com/ntfs-partition-boot-sector.htm NTFS Partition Boot Sector] Information on structure of the boot sector.</ref>
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) and the number of bytes per sector (2 bytes found at 0x0b).  This value is the byte offset to the $MFT, which is described below.

=== {{Anchor|MFT}} Master File Table ===

In NTFS, all file, directory and [[NTFS#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 (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 (software)|Everything]] or [[Ultrasearch]] to locate named local files and folders included in the MFT very fast, without requiring any other index.

The MFT structure supports algorithms which minimize [[file system fragmentation|disk fragmentation]].<ref>{{ cite web | url=https://msdn.microsoft.com/en-us/library/windows/desktop/aa365230(v=vs.85).aspx | title=Master File Table | date=July 2, 2012 | publisher=[[Microsoft Developer Network|MSDN]] }}</ref> A directory entry consists of a filename and a "file ID", 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.

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 sector.<ref>[https://ntfs.com/ntfs-mft.htm NTFS Master File Table (MFT)]. Information on structure of MFT file.</ref>

For protection, in [[Windows 7]], if you attempt to open the MFT via an Administrator [[Command Prompt]], the system will [[BSoD]] with an error code of 0x24 (NTFS_FILE_SYSTEM). In [[Windows 8]], running the same command will bring up an Open File dialogue, but all programs will show [[Access Denied]] errors. The command to "open" the MFT is <code>cd /</code> and then <code>start $mft</code>. Both commands must be run at the same time.

=== 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. 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"
|+ List of NTFS metafiles
! Segment Number !! File Name !! Purpose
|-
| 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.
|-
| 1
| <code>$MFTMirr</code>
| Duplicate of the first vital entries of $MFT, usually 4 entries (4 [[Kilobyte]]s).
|-
| 2
| <code>$LogFile</code>
| Contains transaction log of file system metadata changes.
|-
| 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 $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 $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).
|-
| 4
| <code>$AttrDef</code>
| A table of MFT attributes that associates numeric identifiers with names.
|-
| 5
| <code>.</code>
| [[Root directory]]. Directory data is stored in $INDEX_ROOT and $INDEX_ALLOCATION attributes both named $I30.
|-
| 6
| <code>$Bitmap</code>
| An array of bit entries: each bit indicates whether its corresponding cluster is used (allocated) or free (available for allocation).
|-
| 7
| <code>$Boot</code>
| [[Volume boot record]]. This file is always located at the first clusters on the volume. It contains [[bootstrap code]] (see [[NTLDR]]/[[Windows Vista startup process#Windows Boot Manager|BOOTMGR]]) and a [[BIOS parameter block]] including a [[volume serial number]] and cluster numbers of $MFT and $MFTMirr.
|-
| 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 $Bad and contains all clusters on the volume not in the first stream.
|-
| 9
| <code>$Secure</code>
| [[Access control list]] database that reduces overhead having many identical ACLs stored with each file, by uniquely storing these ACLs in this database only (contains two indices: $SII ''(Standard_Information ID)'' and $SDH ''([[Security Descriptor]] Hash)'', which index the stream named $SDS containing actual ACL table).<ref name="insidewin2kntfs" />
|-
| 10
| <code>$UpCase</code>
| A table of unicode uppercase characters for ensuring case-insensitivity in Win32 and DOS namespaces.
|-
| 11
| <code>$Extend</code>
| A filesystem directory containing various optional extensions, such as $Quota, $ObjId, $Reparse or $UsnJrnl.
|-
| 12–23
| colspan=2 | 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.
|-
| 24
| <code>$Extend\$Quota</code>
| Holds disk quota information. Contains two index roots, named $O and $Q.
|-
| 25
| <code>$Extend\$ObjId</code>
| Holds [[#Distributed Link Tracking (DLT)|link tracking]] information. Contains an index root and allocation named $O.
|-
| 26
| <code>$Extend\$Reparse</code>
| Holds [[reparse point]] data (such as [[symbolic link]]s). Contains an index root and allocation named $R.
|-
| 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.<ref>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>dir /a</code> stopped working, but <code>dir /a \$MFT</code> worked.</ref> 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</code><ref name="support.microsoft.com">{{ cite web | title = OEM Support Tools Phase 3 Service Release 2 Availability | url = https://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 | accessdate = 2010-06-16 }}</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 $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 attribute types.
** This is the case for $STANDARD_INFORMATION attribute that is stored as a fixed-size record and containing the [[timestamp]]s and other basic single-bit attributes (compatible with those managed by [[File Allocation Table|FAT]]/FAT32 in DOS or Windows 95/98 applications).
* 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 only contain 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 filesystem. 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 descriptor]]s 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 named.
* 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 ("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>[https://blogs.technet.com/b/askcore/archive/2009/10/16/the-four-stages-of-ntfs-file-growth.aspx blogs.technet.com: Jeff Hughes, The Four Stages of NTFS File Growth (2009)]</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 $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 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 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.<ref>[https://support.microsoft.com/kb/967351/en-us Microsoft KB: A heavily fragmented file in an NTFS volume may not grow beyond a certain size (2012)]</ref>

The NTFS filesystem 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 files.

=== Opportunistic locks ===

Opportunistic 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>https://msdn.microsoft.com/en-us/library/cc308442.aspx</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>https://technet.microsoft.com/en-us/library/ff383236(WS.10).aspx</ref>

=== Time ===

Windows NT and its descendants keep internal timestamps as [[UTC]] and make the appropriate conversions for display purposes. Therefore, 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 between 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 12 months.<ref>"[https://www.codeproject.com/datetime/dstbugs.asp Beating the Daylight Saving Time bug and getting correct file modification times]" ''The Code Project''</ref>

== Interoperability ==

While the different NTFS versions are for the most part fully [[forward compatibility|forward]]- and [[backward compatibility|backward-compatible]], there are technical considerations for mounting newer NTFS volumes in older versions of Microsoft Windows. 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.<ref>{{ cite web | url=https://blogs.technet.com/filecab/archive/2006/07/14/441829.aspx | title=How restore points and other recovery features in Windows Vista are affected when dual-booting with Windows XP | author=cfsbloggers |date=July 14, 2006 | work=The Filing Cabinet | accessdate=2007-03-21 }}</ref> A Windows command-line utility called [[Convert (command)|convert.exe]] can convert supporting file systems to NTFS, including [[High Performance File System|HPFS]] (only on Windows NT 3.1, 3.5, and 3.51), [[File Allocation Table|FAT16]] and FAT32 (on Windows 2000 and later).<ref>{{ cite web |url=https://www.microsoft.com/technet/prodtechnol/winxppro/maintain/convertfat.mspx |title=How to Convert FAT Disks to NTFS |accessdate=2007-08-27 |date=2001-10-25 |publisher=Microsoft Corporation}}</ref><ref>{{ cite web |url=https://support.microsoft.com/kb/214579 |title=How to use Convert.exe to convert a partition to the NTFS file system |accessdate=2010-12-26 |date=2007-02-12 |publisher=Microsoft Corporation}}</ref>

[[Mac OS X Panther|Mac OS X 10.3]] and later include read-only support for NTFS-formatted partitions. The [[GNU General Public License|GPL]]-licensed [[NTFS-3G]] also works on Mac OS X through [[Filesystem in Userspace|FUSE]] and allows reading and writing to NTFS partitions. A performance enhanced commercial version, called ''[[Tuxera]] NTFS for Mac'',<ref>{{ cite web |url=https://www.tuxera.com/products/tuxera-ntfs-for-mac/ |title=Tuxera NTFS for Mac |date=August 30, 2011 |accessdate=September 20, 2011 |publisher=Tuxera}}</ref> is also available from the NTFS-3G developers. [[Paragon Software Group]] sells a read-write driver named ''NTFS for Mac OS X'',<ref>{{ cite web |url=https://www.paragon-software.com/home/ntfs-mac/release.html |title=NTFS for Mac OS X, communication channel between Mac OS X and Windows |date= |accessdate=September 20, 2011 |publisher=Paragon Software Group}}</ref> which is also included on some models of [[Seagate Technology|Seagate]] hard drives.<ref>[https://www.seagate.com/ww/v/index.jsp?locale=en-US&name=goflex-software&vgnextoid=11c1fab114b48210VgnVCM1000001a48090aRCRD Seagate Read/Write NTFS driver for Mac OS X]</ref> Native NTFS write support has been discovered in [[Mac OS X Snow Leopard|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 panic]]s, probably the reason why write support has not been enabled or advertised.<ref>{{ cite web |url=https://smokingapples.com/software/tutorials/snow-leopards-hidden-ntfs-readwrite-support/ |title=Snow Leopard's hidden NTFS read/write support |author=Alvares, Milind |date=October 2, 2009 |accessdate=18 September 2010}}</ref>

[[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]] drivers (NTFSMount, [[NTFS-3G]] and [[Captive NTFS]], a 'wrapping' driver that uses Windows' own driver, <tt>ntfs.sys</tt>) exist for NTFS support. They are built on the [[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: 
* Tuxera NTFS — A high-performance read/write commercial kernel driver, mainly targeted for embedded devices from [[Tuxera]], which also develops [[NTFS-3G]]; 
* NTFS for Linux — A commercial driver with full read/write support from [[Paragon Software Group]].

[[eComStation]], and [[FreeBSD]] 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]] also works on Mac OS X, FreeBSD, NetBSD, Solaris, [[QNX]] and [[Haiku (operating system)|Haiku]], in addition to Linux, through [[Filesystem in Userspace|FUSE]].<ref>{{ cite web|url=https://www.ntfs-3g.org/|title=NTFS-3G Stable Read/Write Driver|date=2009-07-25}}</ref> A free for personal use read/write driver for [[MS-DOS]] called "NTFS4DOS" also exists.<ref>{{Wayback|url=https://www.free-av.com/en/tools/11/avira_ntfs4dos_personal.html|title=Avira NTFS4DOS Personal|date=20100619161828}}</ref><ref>[https://www.softpedia.com/progDownload/Avira-NTFS4DOS-Personal-Download-104314.html Download of NTFS4DOS.EXE NTFS driver for DOS at Softpedia.com]</ref> [[Ahead Software]] developed a "NTFSREAD" driver (version 1.200) for [[DR-DOS]]&nbsp;7.0x between 2002 and 2004. It was part of their [[Nero Burning ROM]] software. [[OpenBSD]] offer native read-only NTFS support by default on i386 and amd64 platforms as of version 4.9 released 1 May 2011.<ref>https://openbsd.com/49.html</ref> Read/write support through [[NTFS-3G]] are possible in OpenBSD -current as of 1 November 2013 (first release is OpenBSD 5.5 on 1 May 2014) as [[OpenBSD]] henceforth has its own [[Filesystem in Userspace|FUSE]] implementation <ref>{{ cite web|url=https://undeadly.org/cgi?action=article&sid=20131108082749&mode=expanded&count=2 |title=OpenBSD adds fuse(4) support for adding file systems in userland |publisher=[[OpenBSD Journal]] |date=2013-11-08 |accessdate=2013-11-08}}</ref> and [[NTFS-3G]] is available from [[Ports collection|ports]].<ref>{{cite web |url= https://ports.su/sysutils/ntfs-3g |title= ntfs_3g-2014.2.15 – FUSE NTFS driver with read/write support |work= [[OpenBSD ports]] |date= 2014-01-05 |accessdate= 2015-02-14 }}</ref>

== See also ==

* [[Comparison of file systems]]
* [[NTFSDOS]]
* [[ntfsresize]]

== References ==

{{reflist|30em}}

== Further reading ==

{{refbegin}}
* {{cite journal|last1=Bolosky |first1=William J. |last2=Corbin |first2=Scott |last3=Goebel |first3=David |last4=Douceur |first4=John R. |url=https://research.microsoft.com/pubs/74261/WSS2000.pdf|title=Single Instance Storage in Windows 2000|publisher=Microsoft|format=PDF|date=2 December 2008}}
* {{cite book |last= Custer |first= Helen |title= Inside the Windows NT File System |year= 1994 | publisher= [[Microsoft Press]] |isbn= 978-1-55615-660-1}}
* {{cite book |last=Nagar |first= Rajeev |year=1997 |title= Windows NT File System Internals: A Developer's Guide |publisher= [[O'Reilly Media|O'Reilly]] |isbn= 978-1-56592-249-5 }}
{{refend}}

== External links ==

* [https://technet.microsoft.com/en-us/library/cc758691(WS.10).aspx Microsoft: NTFS Technical Reference]
* [https://technet.microsoft.com/en-us/library/cc788058(WS.10).aspx Microsoft: Fsutil file] (documentation for line command useful for manipulating or creating files in an NTFS volume from Windows)
* [https://www.ntfs.com/ LSoft Technologies: NTFS.com] (documentation and resources)

{{Windows Components}}
{{Filesystem}}

[[Category:1993 software]]
[[Category:Compression file systems]]
[[Category:Windows disk file systems]]