View source for NTFS

{{Short description|Proprietary file system developed by Microsoft}}
{{Infobox file system
| developer = [[Microsoft]]
| name = NT File System<ref name="karresand2019">{{Cite journal| doi = 10.1016/j.diin.2019.04.018| issn = 1742-2876| volume = 29| pages = –51–S60| last1 = Karresand| first1 = Martin| last2 = Axelsson| first2 = Stefan| last3 = Dyrkolbotn| first3 = Geir Olav| title = Using NTFS Cluster Allocation Behavior to Find the Location of User Data| journal = Digital Investigation| date = 2019-07-01| s2cid = 199004263| doi-access = free| hdl = 11250/2631756| hdl-access = free}}</ref>
| full_name = NT File System<ref name="ntfs_abbr"/>
| variants = 
| introduction_date = {{Start date and age|1993|07|27}}
| partition_id = {{mono|[[Partition type#PID 07h|0x07]]}} ([[Master boot record|MBR]])<br />{{mono|[[Basic Data Partition|EBD0A0A2-B9E5-4433-87C0-68B6B72699C7]]}} ([[GUID Partition Table|GPT]])
| directory_struct = [[B-tree]] variant<ref name="How NTFS Works">{{cite web|title=How NTFS Works|url=https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc781134(v=ws.10)|work=Windows Server 2003 Technical Reference |date=8 October 2009 |publisher=Microsoft|access-date=25 January 2025}}</ref><ref>{{cite web|access-date=2019-05-13|title=B*Trees – NTFS Directory Trees – Concept – NTFS Documentation|url=https://flatcap.org/linux-ntfs/ntfs/concepts/tree/index.html|website=flatcap.org|archive-date=2019-05-13|archive-url=https://web.archive.org/web/20190513230245/https://flatcap.org/linux-ntfs/ntfs/concepts/tree/index.html|url-status=dead}}</ref>
| file_struct = Bitmap
| bad_blocks_struct = $BadClus (MFT Record)
| max_volume_size = 2<sup>64</sup> [[Data cluster|clusters]] − 1 cluster (format);<br />256{{nbsp}}[[terabyte|TB]]{{efn|name=units|1={{CompUnits|KBMBGBTBPBEB}}}} − 64{{nbsp}}[[kilobyte|KB]]{{efn|name=units}} ([[Windows 10]] version 1703, [[Windows Server 2016]] or earlier implementation)<ref name="How NTFS Works"/><br />8{{nbsp}}[[petabyte|PB]]{{efn|name=units}} − 2{{nbsp}}[[megabyte|MB]]{{efn|name=units}} (Windows 10 version 1709, [[Windows Server 2019]] or later implementation)<ref name="MS-FSA_id_1" />
| max_file_size = 16{{nbsp}}[[exabyte|EB]]{{efn|name=units}}&nbsp;− 1{{nbsp}}[[kilobyte|KB]] (format);<br />16{{nbsp}}[[terabyte|TB]]&nbsp;− 64{{nbsp}}[[kilobyte|KB]] ([[Windows 7]], [[Windows Server 2008 R2]] or earlier implementation)<ref name="How NTFS Works"/><br />256{{nbsp}}[[terabyte|TB]]&nbsp;− 64{{nbsp}}[[kilobyte|KB]] ([[Windows 8]], [[Windows Server 2012]] or later implementation)<ref name="MS-FSA">{{cite web |url= https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fsa/4e3695bd-7574-4f24-a223-b4679c065b63 |title= Appendix A: Product Behavior |work= [MS-FSA]: File System Algorithms |publisher= Microsoft |date= 14 November 2013 |access-date= 2012-09-21}}</ref><br />8{{nbsp}}[[petabyte|PB]] − 2{{nbsp}}[[megabyte|MB]] (Windows 10 version 1709, [[Windows Server 2019]] or later implementation)<ref name="MS-FSA_id_1" />
| max_files_no = 4,294,967,295 (2<sup>32</sup>−1)<ref name="How NTFS Works" />
| max_filename_size = 255 [[UTF-16]] code units<ref name="ntfsdoc">{{cite web |url= http://dubeyko.com/development/FileSystems/NTFS/ntfsdoc.pdf |archive-url=https://ghostarchive.org/archive/20221009/http://dubeyko.com/development/FileSystems/NTFS/ntfsdoc.pdf |archive-date=2022-10-09 |url-status=live |title= NTFS Documentation |first1= Richard |last1= Russon |first2= Yuval |last2= Fledel |access-date= 2011-06-26}}</ref>
| dates_recorded = Creation, modification, POSIX change, access
| date_range = 1 January 1601 – 14 Sept 30828 or 28 May 60056 (File times are 64-bit numbers counting 100-nanosecond intervals (ten million per second) from 1601){{efn|name=date-limit}}
| date_resolution = 100 ns
| forks_streams = Yes (see {{section link||Alternate data stream (ADS)}} below)
| attributes = Read-only, hidden, system, archive, not content indexed, off-line, temporary, compressed, encrypted
| file_system_permissions = [[Access Control List|ACLs]]
| compression = Per-file, [[LZ77]] ([[Windows NT 3.51]] onward)
| 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 />[[Mac OS X 10.3]] and later (read-only)<br />[[Linux kernel]] version 2.6 and later<br />Linux kernel versions 2.2–2.4 (read-only)<br />[[FreeBSD]]<br />[[NetBSD]]<br/>[[OpenBSD]] (read-only)<br />[[ChromeOS]]<br />[[Oracle Solaris|Solaris]]<br />[[ReactOS]] (read-only)
| filename_character_set = {{Plainlist|
* In [[Win32]] namespace: any [[UTF-16]] code unit (case-insensitive) except <code>/\:*"?&lt;&gt;&#124;</code> as well as [[null character|NUL]]<ref name="ntfsdoc"/>
* In [[POSIX]] namespace: any [[UTF-16]] code unit (case-sensitive) except <code>/</code> as well as [[null character|NUL]]
  }}
| introduction_os = [[Windows NT 3.1]]
| single_instance_storage = Yes ([[Windows Server 2012]])<ref name="singleinstancestorage">{{cite web |url= https://www.techrepublic.com/blog/the-enterprise-cloud/windows-server-8-data-deduplication-what-you-need-to-know/ |title= Windows Server 8 data deduplication |author= Rick Vanover |date= 14 September 2011 |access-date= 2011-12-02 |archive-date= 2016-07-18 |archive-url= https://web.archive.org/web/20160718150957/http://www.techrepublic.com/blog/the-enterprise-cloud/windows-server-8-data-deduplication-what-you-need-to-know/ |url-status= dead }}</ref>
}}
'''NT File System''' ('''NTFS''') is a proprietary [[journaling file system]] developed by [[Microsoft]] in the 1990s.<ref>{{cite book |doi=10.1007/978-1-84628-732-9_6 |chapter=The New Technology File System |title=Forensic Computing |date=2007 |pages=215–275 |isbn=978-1-84628-397-0 }}</ref><ref>{{Cite web |last=Weiss |first=David |date=2022-08-01 |title=What Is NTFS and How Does It Work? |url=https://www.datto.com/blog/what-is-ntfs-and-how-does-it-work/ |access-date=2024-08-14 |website=Datto |language=en-US}}</ref><ref name="ntfs_abbr">{{cite web |url=https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-efsr/230807ac-20be-494f-86e3-4c8ac23ea584 |title=Glossary |work=[MS-EFSR]: Encrypting File System Remote (EFSRPC) Protocol |publisher=Microsoft |date=14 November 2013}}</ref>

It was developed to overcome scalability, security and other limitations with [[File Allocation Table|FAT]].<ref>{{cite book |doi=10.1016/B978-0-12-804449-0.00004-X |chapter=Data Hiding Under Windows® OS File Structure |title=Data Hiding Techniques in Windows OS |date=2017 |last1=Hassan |first1=Nihad Ahmad |last2=Hijazi |first2=Rami |pages=97–132 |isbn=978-0-12-804449-0 }}</ref> NTFS adds several features that [[File Allocation Table|FAT]] and [[HPFS (file system)|HPFS]] lack, including: [[access control list]]s (ACLs); filesystem encryption; transparent compression; [[sparse file]]s; [[Journaling file system|file system journaling]] and [[shadow copy|volume shadow copy]], a feature that allows backups of a system while in use.

Starting with [[Windows NT 3.1]], it is the default file system of the [[Windows NT]] family superseding the [[File Allocation Table]] (FAT) file system.<ref name="Custer, Helen">{{cite book |last=Custer |first=Helen |url=https://archive.org/details/insidewindowsntf00cust |title=Inside the Windows NT File System |publisher=[[Microsoft Press]] |year=1994 |isbn=978-1-55615-660-1}}</ref> NTFS read/write support is available on [[Linux]] and [[Berkeley Software Distribution|BSD]] using [[NTFS3]] in [[Linux kernel|Linux]] and [[NTFS-3G]] in both Linux and [[BSD]].<ref>{{Cite web|title=NTFS3 — The Linux Kernel documentation|url=https://www.kernel.org/doc/html/latest/filesystems/ntfs3.html|access-date=2021-12-02|website=www.kernel.org}}</ref><ref>{{Cite web|title=ntfs-3g|url=https://www.freebsd.org/cgi/man.cgi?query=ntfs-3g&format=html|access-date=2021-12-02|website=www.freebsd.org}}</ref><ref>[https://archlinux.org/packages/extra/x86_64/ntfs-3g/ Arch Linux - ntfs-3g 2022.10.3-1 (x86_64)]</ref>

NTFS uses several files hidden from the user to store metadata about other files stored on the drive which can help improve speed and performance when reading data.<ref name="karresand2019" />

NTFS was slated to be replaced by [[WinFS]], one of the anchor features of the [[Development of Windows Vista|Longhorn]] platform, however WinFS was cancelled after Microsoft was unable to resolve performance problems with the filesystem.

== History ==
In the mid-1980s, [[Microsoft]] and [[IBM]] formed a joint project to create the next generation of graphical [[operating system]]; the result was [[OS/2]] and [[High Performance File System|HPFS]]. Because Microsoft disagreed with IBM on many important issues, they eventually separated; OS/2 remained an IBM project and Microsoft worked to develop [[Windows NT]] and NTFS.

The [[High Performance File System|HPFS]] file system for OS/2 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.karlstechnology.com/blog/history-of-ntfs/  |title= Overview and History of NTFS |publisher= The PC Guide |last=Kozierok |first=Charles  |date= 14 February 2018 |access-date=May 30, 2019}}</ref> The original NTFS developers were [[Tom Miller (computer programmer)|Tom Miller]], Gary Kimura, Brian Andrew, and David Goebel.<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 |url= https://archive.org/details/insidewindowsntf00cust}}</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 highly unusual, since there were dozens of unused code numbers available, and other major file systems have their own codes. For example, 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 to distinguish between HPFS and NTFS.

=== Versions ===
Microsoft has released five versions of NTFS:
{| class="wikitable plainrowheaders"
! NTFS version number
! First operating system
! Release date
! New features
! Remarks
|-
! scope=row | 1.0
| [[Windows NT 3.1]]
| 1993<ref name="Custer, Helen" />
| Initial version
| NTFS 1.0 is incompatible with 1.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=http://support.microsoft.com/kb/q129102/|title=Recovering Windows NT After a Boot Failure on an NTFS Drive|date=November 1, 2006|publisher=Microsoft}}</ref>
|-
! scope=row | 1.1
| [[Windows NT 3.5]]
| 1994
| Named streams and [[access control list]]s<ref name="insidewin2kntfs">{{cite web |url=https://learn.microsoft.com/en-us/previous-versions/ms995846(v=msdn.10) |title=Inside Win2K NTFS, Part 1 |last=Russinovich |first=Mark |author-link=Mark Russinovich |website=[[Microsoft Learn]] |date=30 June 2006 |publisher=[[Microsoft]] |access-date=2008-04-18}}</ref>
| NTFS compression support was added in [[Windows NT 3.51]]
|-
! scope=row | 1.2
| [[Windows NT 4.0]]
| 1996
| [[Security descriptor]]s
| Commonly called NTFS 4.0 after the OS release
|-
! scope=row | 3.0
| [[Windows 2000]]
| 2000
| Disk quotas,  file-level encryption in a form of [[Encrypting File System]], [[sparse file]]s, [[NTFS reparse point|reparse points]], [[USN Journal|update sequence number (USN) journaling]], distributed link tracking, the <code>$Extend</code> folder and its files
| Compatibility was also made available for Windows NT 4.0 with the Service Pack 4 update. Commonly called NTFS 5.0 after the OS release.<ref>{{cite web |url=http://www.microsoft.com/ntserver/nts/exec/overview/NT4SP4whatnew.asp |title=What's New in Windows NT 4.0 Service Pack 4? |date=12 January 1999 |website=Microsoft.com |access-date=17 August 2018 |url-status=dead |archive-url=https://web.archive.org/web/19990117055557/http://www.microsoft.com/ntserver/nts/exec/overview/NT4SP4whatnew.asp |archive-date=17 January 1999}}</ref>
|-
! scope=row | 3.1
| [[Windows XP]]
| October 2001
| Expanded the [[#Master File Table|Master File Table]] (MFT) entries with redundant MFT record number (useful for recovering damaged MFT files)
| Commonly called NTFS 5.1 after the OS release. LFS version 1.1 was replaced by version 2.0 as of Windows 8 to improve performance.
|}

The {{code|NTFS.sys}} version number (e.g. v5.0 in Windows 2000) is based on the operating system version; it should not be confused with the NTFS version number (v3.1 since Windows XP).<ref>{{cite web |archive-url=https://web.archive.org/web/20061116110405/http://support.microsoft.com/kb/310749 |url=http://support.microsoft.com/kb/310749 |title=New Capabilities and Features of the NTFS 3.1 File System |publisher=Microsoft |date=1 December 2007 |archive-date=Nov 16, 2006}}</ref><ref>{{cite web |url=https://www.ntfs.com/ntfs_basics.htm |title=NTFS Overview |publisher=LSoft Technologies Inc.}}</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=http://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 |access-date=2007-09-04 |format=PowerPoint |pages=14–20 |last=Loveall |first=John |year=2006}}</ref> NTFS symbolic links are a new feature in the file system; all the others are new operating system features that make use of NTFS features already in place.

== Scalability ==
NTFS is optimized for 4&nbsp;[[kilobyte|KB]]{{efn|name=units}} [[Data cluster|clusters]], but supports a maximum cluster size of 2{{nbsp}}[[megabyte|MB]]{{efn|name=units}}. (Earlier implementations support up to 64{{nbsp}}KB)<ref name="MS-FSA_id_1">{{cite web |url= https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fsa/4e3695bd-7574-4f24-a223-b4679c065b63#Appendix_A_1 |title= Appendix A: Product Behavior |work= [MS-FSA]: File System Algorithms |publisher= Microsoft|date= 2018-09-12 |access-date= 2018-10-01 |quote= NTFS uses a default cluster size of 4 KB, a maximum cluster size of 64 KB on Windows 10 v1703 operating system and Windows Server 2016 and prior, and 2 MB on Windows 10 v1709 operating system and Windows Server 2019 and later, and a minimum cluster size of 512 bytes.}}</ref> The maximum NTFS volume size that the specification can support is {{nowrap|2<sup>64</sup> − 1}} clusters, but not all implementations achieve this theoretical maximum, as discussed below.

The maximum NTFS volume size implemented in Windows XP Professional is {{nowrap|2<sup>32</sup> − 1}} clusters, partly due to partition table limitations. For example, using 64{{nbsp}}KB clusters, the maximum size Windows XP NTFS volume is 256{{nbsp}}[[terabyte|TB]] minus 64{{nbsp}}[[kilobyte|KB]]. Using the default cluster size of 4{{nbsp}}KB, the maximum NTFS volume size is 16{{nbsp}}TB minus 4{{nbsp}}KB. Both of these are vastly higher than the 128{{nbsp}}[[gigabyte|GB]]{{efn|name=units}} limit in [[Windows XP#Service Pack 1|Windows XP SP1]]. The size of a partition in the Master Boot Record (MBR) is limited to 2 TiB with a hard drive with 512-byte physical sectors,<ref>{{cite web |title=Windows support for hard disks that are larger than 2 TB |website=[[Microsoft Learn]] |date=2013-06-26 |url=https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/support-for-hard-disks-exceeding-2-tb |access-date=2024-08-08}}</ref><ref>{{cite web |title=Default cluster size for NTFS, FAT, and exFAT |url=https://support.microsoft.com/en-us/topic/default-cluster-size-for-ntfs-fat-and-exfat-9772e6f1-e31a-00d7-e18f-73169155af95|website=Microsoft Support|archive-url=https://web.archive.org/web/20240309213220/https://support.microsoft.com/en-us/topic/default-cluster-size-for-ntfs-fat-and-exfat-9772e6f1-e31a-00d7-e18f-73169155af95|archive-date=2024-03-09|url-status=dead}}</ref> although for a 4 KiB physical sector the MBR partition size limit is 16 TiB. An alternative is to use multiple [[GUID Partition Table]] (GPT or "dynamic") volumes for be combined to create a single NTFS volume larger than 2 TiB. 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{{Efn|Can also be 32-bit, provided that the firmware and operating system loader are size-matched.}} support.<ref>{{cite web|url=http://www.rodsbooks.com/gdisk/booting.html|title=Booting from GPT|website=Rodsbooks.com|access-date=22 September 2018}}</ref> GPT data disks are supported on systems with BIOS.

The NTFS maximum theoretical limit on the size of individual files is 16{{nbsp}}[[Exabyte|EB]]{{efn|name=units}}<ref>{{Cite web|title=NTFS vs FAT vs exFAT – NTFS.com|url=https://www.ntfs.com/ntfs_vs_fat.htm|access-date=2021-01-19|website=www.ntfs.com}}</ref> ({{nowrap|16 × 1024<sup>6</sup>}} or {{nowrap|2<sup>64</sup> bytes}}) minus 1{{nbsp}}KB, which totals 18,446,744,073,709,550,592 bytes. With [[Windows 10]] version 1709 and [[Windows Server 2019]], the maximum ''implemented'' file size is 8{{nbsp}}PB{{efn|name=units}} minus 2{{nbsp}}MB or 9,007,199,252,643,840 bytes.<ref name="MS-FSA_id_1"/>

== Interoperability ==

=== Windows ===
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 Windows' feature "Previous Versions" ([[Volume Shadow Copy]]) on an operating system that does not support it will result in the contents of those previous versions being lost.<ref name="techBlog2007">{{cite web |author=cfsbloggers |date=July 14, 2006 |title=How restore points and other recovery features in Windows Vista are affected when dual-booting with Windows XP |url=http://blogs.technet.com/filecab/archive/2006/07/14/441829.aspx |url-status=dead |archive-url=https://web.archive.org/web/20060718011852/http://blogs.technet.com/filecab/archive/2006/07/14/441829.aspx |archive-date=2006-07-18 |access-date=2007-03-21 |work=The Filing Cabinet}}</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). The conversion occurs in-place, meaning the existing files stay where they are and are not re-written during the process. The process is not reversible without formatting and writing the files again.<ref>{{cite web |url= https://www.karlstechnology.com/blog/convert-fat-disks-to-ntfs/  |title= How to Convert FAT Disks to NTFS |date= 18 December 2017 |website=Karl's Technology |access-date=May 30, 2019}}</ref><ref>{{cite web |url=https://www.eduhk.hk/ocio/content/faq-how-convert-fat32-file-system-ntfs-windows-xp |title=FAQ: How to use Convert.exe to convert a partition to the NTFS file system |access-date=2010-12-26 |date=2007-02-12 |website=The Educationsl University of Hong Kong |archive-url=https://web.archive.org/web/20231206011046/https://www.eduhk.hk/ocio/content/faq-how-convert-fat32-file-system-ntfs-windows-xp |archive-date=2023-12-06 |url-status=dead}}</ref>

=== FreeBSD ===
[[FreeBSD]] 3.2 released in May 1999 included read-only NTFS support written by {{not a typo|Semen}} Ustimenko.<ref>{{cite web | url=https://www.freebsd.org/releases/3.2R/notes.html | title=FreeBSD 3.2 Release Notes | date=17 May 1999 | access-date=2020-06-15 }}</ref><ref name=OpenBSDman /> This implementation was ported to [[NetBSD]] by Christos Zoulas and Jaromir Dolecek and released with NetBSD 1.5 in December 2000.<ref>{{cite web | url=https://www.netbsd.org/releases/formal-1.5/NetBSD-1.5.html | title=Announcing NetBSD 1.5 | date=6 December 2000 | access-date=2020-06-15 }}</ref> The FreeBSD implementation of NTFS was also ported to [[OpenBSD]] by Julien Bordet and offers native read-only NTFS support by default on i386 and amd64 platforms {{as of|lc=y|pre=version 4.9 released|2011|05|01|post=.}}<ref>{{cite web|url=http://openbsd.com/49.html|title=OpenBSD 4.9|website=Openbsd.com|access-date=22 September 2018}}</ref><ref name=OpenBSDman>{{cite web | url=https://man.openbsd.org/mount_ntfs.8 | title=mount_ntfs – OpenBSD manual pages | access-date=2020-06-15 }}</ref>

=== Linux ===
[[Linux kernel]] versions 2.1.74 and later include a driver written by Martin von Löwis which has the ability to read NTFS partitions;<ref name="LinuxNTFSCredits">{{cite web |title=NTFS Credits and History |url=https://flatcap.org/linux-ntfs/misc.html |url-status=dead |archive-url=https://web.archive.org/web/20210924232137/https://flatcap.org/linux-ntfs/misc.html |archive-date=2021-09-24 |accessdate=2021-09-24 |work=Linux-NTFS Project}}</ref> kernel versions 2.5.11 and later contain a new driver written by Anton Altaparmakov ([[University of Cambridge]]) and Richard Russon which supports file read.<ref>{{cite web | url=https://lwn.net/2002/0502/kernel.php3 | title=Kernel development | date=2 May 2002 | work=lwn.net | accessdate=2021-09-05 }}</ref><ref>{{cite web | url=https://cdn.kernel.org/pub/linux/kernel/v2.5/ChangeLog-2.5.11 | title=Release notes for v2.5.11 | date=29 April 2002 | accessdate=2021-09-05 }}</ref><ref name=LinuxNTFSCredits /> The ability to write to files was introduced with kernel version 2.6.15 in 2006 which allows users to write to existing files but does not allow the creation of new ones.<ref>{{cite web | url=https://kernelnewbies.org/Linux_2_6_15 | title=2.6.15 changelog | date=3 January 2006 | work=Linux project | access-date=2021-09-05 |archive-url=https://web.archive.org/web/20210905125357/https://kernelnewbies.org/Linux_2_6_15 |archive-date=2021-09-05 |url-status=dead}}</ref> Paragon's NTFS driver (see below) has been merged into kernel version 5.15, and it supports read/write on normal, compressed and sparse files, as well as journal replaying.<ref>{{Cite web|url=https://www.theregister.com/2021/09/06/github_merges_useless_garbage_says/|title=GitHub merges 'useless garbage' says Linus Torvalds as new NTFS support added to Linux kernel 5.15|date=2021-09-06|access-date=2021-09-07|website=The Register|last=Anderson|first=Tim}}</ref>

[[NTFS-3G]] is a free [[GNU General Public License|GPL]]-licensed [[Filesystem in Userspace|FUSE]] implementation of NTFS that was initially developed as a Linux kernel driver by Szabolcs Szakacsits. It was re-written as a FUSE program to work on other systems that FUSE supports like [[macOS]], FreeBSD, NetBSD, [[OpenBSD]],<ref>{{cite web |url=http://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 |access-date=2013-11-08}}</ref> Solaris, [[QNX]], and [[Haiku (operating system)|Haiku]]<ref>{{cite web |url=http://www.ntfs-3g.org/|title=NTFS-3G Stable Read/Write Driver |date=2009-07-25}}</ref> and allows reading and writing to NTFS partitions. A performance enhanced commercial version of NTFS-3G, called "[[Tuxera]] NTFS for Mac", is also available from the NTFS-3G developers.<ref>{{cite web |url=http://www.tuxera.com/products/tuxera-ntfs-for-mac/ |title=Tuxera NTFS for Mac |date=August 30, 2011 |access-date=September 20, 2011 |publisher=Tuxera}}</ref>

[[Captive NTFS]], a 'wrapping' driver that uses Windows' own driver {{mono|ntfs.sys}}, exists for Linux. It was built as a [[Filesystem in Userspace]] (FUSE) program and released under the GPL but work on Captive NTFS ceased in 2006.<ref>{{cite web | url=http://www.jankratochvil.net/project/captive/ | title=Jan Kratochvil: Captive: The first free NTFS read/write filesystem for GNU/Linux | access-date=2020-06-15 }}</ref>

Linux kernel versions 5.15 onwards carry NTFS3, a fully functional NTFS Read-Write driver which works on NTFS versions up to 3.1 and is maintained primarily by the [[Paragon Software Group]].

=== macOS ===
[[Mac OS X Panther|Mac OS X 10.3]] included Ustimenko's read-only implementation of NTFS from FreeBSD. Then in 2006 Apple hired Anton Altaparmakov to write a new NTFS implementation for [[Mac OS X Snow Leopard|Mac OS X 10.6]].<ref>{{cite web | url=https://www.tuxera.com/company/our-story/ | title=About Tuxera | access-date=2020-06-15}}</ref> Native NTFS write support is included in 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.<ref>{{cite web |url=http://hints.macworld.com/article.php?story=20090913140023382 |title=10.6: Enable native NTFS read/write support  |date=1 October 2009 |access-date=5 September 2021 |archive-url=https://web.archive.org/web/20210905122854/http://hints.macworld.com/article.php?story=20090913140023382 |archive-date=5 September 2021 |url-status=dead}}</ref>

[[Paragon Software Group]] sells a read-write driver named ''NTFS for Mac'',<ref>{{cite web |url=https://www.paragon-software.com/home/ntfs-mac/ |title=Microsoft NTFS for Mac |access-date=August 8, 2024 |publisher=Paragon Software Group}}</ref> which is also included on some models of [[Seagate Technology|Seagate]] hard drives.<ref>{{Cite web|url=http://www.seagate.com/ww/v/index.jsp?locale=en-US&name=goflex-software&vgnextoid=11c1fab114b48210VgnVCM1000001a48090aRCRD|archive-url=https://web.archive.org/web/20110210152004/http://www.seagate.com/ww/v/index.jsp?locale=en-US&name=goflex-software&vgnextoid=11c1fab114b48210VgnVCM1000001a48090aRCRD |url-status=dead |title=The Leader in Mass Data Storage Solutions &#124; Seagate US|archive-date=February 10, 2011|website=Seagate.com}}</ref> 

=== OS/2 ===
The NetDrive package for [[OS/2]] (and derivatives such as [[eComStation]] and [[ArcaOS]]) supports a plugin which allows read and write access to NTFS volumes.<ref>{{cite web|url=https://ecsoft2.org/ntfs-plugin-netdrive|access-date=2020-09-09|website=ecsoft2.org|title=NTFS plugin for NetDrive}}</ref><ref>{{cite web|url=https://www.arcanoae.com/shop/netdrive-for-os2/|title=NetDrive for OS/2|access-date=2020-09-09|website=arcanoae.com}}</ref>

=== DOS ===
There is a free-for-personal-use read/write driver for [[MS-DOS]] by [[Avira]] called "NTFS4DOS".<ref>{{cite web |url=http://www.free-av.com/en/tools/11/avira_ntfs4dos_personal.html |title=Avira NTFS4DOS Personal |access-date=2009-07-25 |url-status=dead |archive-url=https://web.archive.org/web/20100619161828/http://www.free-av.com/en/tools/11/avira_ntfs4dos_personal.html |archive-date=June 19, 2010}}</ref><ref>{{cite web |url=http://www.softpedia.com/progDownload/Avira-NTFS4DOS-Personal-Download-104314.html |title=Download Avira NTFS4DOS Personal 1.9 |access-date=22 September 2018 |url-status=dead |archive-date=10 November 2013 |archive-url=https://web.archive.org/web/20131110224951/http://www.softpedia.com/progDownload/Avira-NTFS4DOS-Personal-Download-104314.html }}</ref>

[[Ahead Software]] developed a "NTFSREAD" driver (version 1.200) for [[DR-DOS]] 7.0x between 2002 and 2004. It was part of their [[Nero Burning ROM]] software.

== Security ==
NTFS uses [[access control list]]s and user-level encryption to help secure user data.

=== Access control lists (ACLs) ===
[[File:NTPermissions.png|thumb|right|200px|NTFS file system permissions on a modern [[Windows]] system]]
In NTFS, each file or folder is assigned a [[security descriptor]] that defines its owner and contains two [[access control list]]s (ACLs). The first ACL, called [[discretionary access control]] list (DACL), defines exactly what type of interactions (e.g. reading, writing, executing or deleting) are allowed or forbidden by which user or groups of users. For example, files in the {{code|C:\Program Files}} folder may be read and executed by all users but modified only by a user holding administrative privileges.<ref name=":0">{{cite web |url= https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc781716(v=ws.10)|title= How Security Descriptors and Access Control Lists Work|access-date= 4 September 2015|website= [[Microsoft Learn]]|date= 8 October 2009|publisher= [[Microsoft]]}}</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 which interactions with the file or folder are 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 they succeed.<ref name=":0"/>

=== Encryption ===
{{Main|Encrypting File System}}

[[Encrypting File System]] (EFS) provides user-transparent encryption of any file or folder on an NTFS volume.<ref>{{cite web |url=https://learn.microsoft.com/en-us/previous-versions/technet-magazine/cc162507(v=msdn.10) |title=Security Watch Deploying EFS: Part 1 |first=John |last=Morello |work=Technet Magazine |publisher=[[Microsoft]] |date=February 2007 |access-date=2025-01-25}}</ref> 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 data stream. 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://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc962103(v=technet.10)|work=Windows 2000 Server Resource Kit|date=18 July 2012 |publisher=[[Microsoft]]|access-date=25 January 2025}}</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, meaning they can not be used for the same files at the same time; 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.

== Features ==

=== Journaling ===
NTFS is a [[journaling file system]] and uses the NTFS Log ({{mono|$LogFile}}) 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 [[#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.

The ({{mono|$LogFile}}) format has evolved through several versions:

{| class="wikitable plainrowheaders"
!Windows Version
!{{mono|$LogFile}} format version
|-
! scope=row |[[Windows NT 4.0]]
|rowspan="5"|1.1
|-
! scope=row |[[Windows 2000]]
|-
! scope=row |[[Windows XP]]
|-
! scope=row |[[Windows Vista]]
|-
! scope=row |[[Windows 7]]
|-
! scope=row |[[Windows 8]]
|rowspan="4"|2.0
|-
! scope=row |[[Windows 8.1]]
|-
! scope=row |[[Windows 10]]
|-
! scope=row |[[Windows 11]]
|}

The incompatibility of the {{mono|$LogFile}} versions implemented by [[Windows 8]], [[Windows 10]], [[Windows 11]] prevents [[Windows 7]] (and earlier versions of Windows) from recognizing version 2.0 of the {{mono|$LogFile}}. Backward compatibility is provided by downgrading the {{mono|$LogFile}} 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 {{mono|$LogFile}}s of any active file systems are not downgraded to version 1.1. The inability to process version 2.0 of the {{mono|$LogFile}} 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 {{mono|$LogFile}} to the newer version. The problem can also be dealt with by disabling Hybrid Boot.<ref>{{Cite web|url=https://learn.microsoft.com/en-us/archive/technet-wiki/15645.windows-8-volume-compatibility-considerations-with-prior-versions-of-windows|title=Windows 8 volume compatibility considerations with prior versions of Windows|date=17 January 2024 |access-date=2024-08-08}}</ref>

The [[USN Journal]] (Update Sequence Number Journal) is a system management feature that records (in {{mono|$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://learn.microsoft.com/en-us/windows/win32/fileio/change-journals|title=Change Journals|date=7 January 2021 |website=[[Microsoft Learn]]|publisher=[[Microsoft]]|access-date=2023-08-12}}</ref> This journal can be enabled or disabled on non-system volumes.<ref>{{cite web|url=https://learn.microsoft.com/en-us/windows/win32/fileio/creating-modifying-and-deleting-a-change-journal|title=Creating, Modifying, and Deleting a Change Journal (Windows)|date=7 January 2021 |website=[[Microsoft Learn]]|publisher=[[Microsoft]]|access-date=2023-08-12}}</ref>

=== 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 [[#Master File Table|MFT]].
Hard links were originally included to support the [[POSIX]] subsystem in Windows NT.<ref>{{cite web|title=Chapter 29 – POSIX Compatibility|url=https://learn.microsoft.com/en-us/previous-versions//cc768080(v=technet.10)|work=MS Windows NT Workstation 4.0 Resource Guide|publisher=[[Microsoft]]|access-date=25 January 2025|year=1995}}</ref>

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.<ref>{{cite web|title=Hard Links and Junctions|url=https://learn.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions|website=[[Microsoft Learn]]|publisher=[[Microsoft]]|access-date=25 January 2025|date=21 June 2024}}</ref> 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 [[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, 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 link]]s on a file.<ref>{{cite web |title=CreateHardLinkA function (winbase.h) |date=June 2023 |url=https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createhardlinka|access-date=25 January 2025}}</ref>{{clarify|is this a limitation of the NTFS on-disk data structure or of Windows NT for all file systems that support hard links?|date=December 2024}}

=== Alternate data stream (ADS) ===
{{main|Fork (file system)}}
{{see also|Mark of the Web}}
Alternate data streams allow more than one [[stream (computing)#Other uses|data stream]] to be associated with a filename (a [[fork (file system)|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<ref>{{cite web|url=https://learn.microsoft.com/en-us/sysinternals/downloads/streams|title=Streams – Sysinternals|website=[[Microsoft Learn]]|publisher=[[Microsoft]]|date=23 March 2021 |access-date=12 August 2023}}</ref> 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.<ref>{{cite web|title=FileSystem Provider|url=https://technet.microsoft.com/en-us/library/hh847764(v=wps.620).aspx|publisher=Microsoft|access-date=23 January 2015|date=9 August 2012|url-status=dead|archive-url=https://web.archive.org/web/20150123140513/https://technet.microsoft.com/en-us/library/hh847764(v=wps.620).aspx|archive-date=23 January 2015}}</ref>

A small ADS named <code>Zone.Identifier</code> 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.<ref>{{cite book |title= Windows Internals |edition= 5th |last1= Russinovich |first1= Mark E. |author-link= 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. This functionality is also known as "[[Mark of the Web]]".<ref>{{Cite web |last=Boyd |first=Christopher |title=Malformed signature trick can bypass Mark of the Web |url=https://www.malwarebytes.com/blog/news/2022/10/malware-authors-use-malformed-signature-trick-to-bypass-mark-of-the-web |access-date=2023-05-15 |website=Malwarebytes |date=26 October 2022 |language=en}}</ref><ref>{{Cite web |last=DHB-MSFT |title=Macros from the internet are blocked by default in Office – Deploy Office |url=https://learn.microsoft.com/en-us/deployoffice/security/internet-macros-blocked |access-date=2023-05-15 |website=[[Microsoft Learn]] |date=28 February 2023 |language=en-us}}</ref> All [[Chromium (browser)|Chromium]] (e.g. [[Google Chrome]]) and [[Firefox]]-based web browsers also write the <code>Zone.Identifier</code> stream to downloaded files.

[[Malware]] has used alternate data streams to hide code.<ref>{{cite web |url=https://www.auscert.org.au/render.html?it=7967 |title=Malware utilising Alternate Data Streams? |website=AusCERT Web Log |date=21 August 2007 |archive-url=https://web.archive.org/web/20110223051226/https://www.auscert.org.au/render.html?it=7967 |archive-date=2011-02-23 |url-status=dead}}</ref> 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 <code>Zone.Identifier</code> 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.<ref>{{cite web | url=https://github.com/fafalone/ZoneStripper | title=Fafalone/ZoneStripper | website=[[GitHub]] }}</ref>

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.

=== 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 [[data compression|compressed]] using LZNT1 algorithm (a variant of [[LZ77]]).<ref>{{cite web |url=http://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 |access-date=2005-08-18}}</ref> The compression algorithm is designed to support cluster sizes of up to 4&nbsp;KB; when the cluster size is greater than 4&nbsp;KB on an NTFS volume, NTFS compression is not available.<ref>{{cite web |url= http://support.microsoft.com/kb/314878 |title= The Default Cluster Size for the NTFS and FAT File Systems |publisher= Microsoft |date= January 31, 2002 |access-date= 2012-01-10}}</ref> Data is compressed in 16-cluster chunks (up to 64&nbsp;KB in size); 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 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 4{{nbsp}}KB to 64{{nbsp}}KB or more, depending on compressibility. Files smaller than approximately 900&nbsp;bytes are stored within the directory entry of the [[#Master File Table|MFT]].<ref name="How NTFS Works" />

For operating systems besides Windows, all versions of the NTFS-3G driver support reading compressed files according to its developers, but support for appending data to compressed files, which means adding new data resulting in increasing the size of a file, was added in November 2009. Overwriting existing compressed data is supported since August 2010.<ref>{{cite web |author1=Jean-Pierre André |title=Data Compression |url=http://www.tuxera.com/community/ntfs-3g-advanced/data-compression/ |website=Tuxera |access-date=25 April 2025 |archive-url=https://archive.today/20130630121815/http://www.tuxera.com/community/ntfs-3g-advanced/data-compression/ |archive-date=2013-06-30 |url-status=dead}}</ref>

==== Advantages ====
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. Even when SSD controllers already compress data, there is still a reduction in I/Os since less data is transferred.<ref>{{cite web |url=http://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 |access-date= 2013-04-05}}</ref>

According to research by Microsoft's NTFS Development team, 50–60{{nbsp}}[[Gigabyte|GB]] is a reasonable maximum size for a compressed file on an NTFS volume with a 4{{nbsp}}KB (default) cluster (block) size. This reasonable maximum size decreases sharply for volumes with smaller cluster sizes.<ref name="understanding-ntfs-compression" /> 

==== Disadvantages ====
Large compressible files become highly fragmented since every chunk smaller than 64{{nbsp}}KB becomes a fragment.<ref name="understanding-ntfs-compression">{{cite web |url=http://blogs.msdn.com/b/ntdebugging/archive/2008/05/20/understanding-ntfs-compression.aspx |title=Understanding NTFS Compression |work=Ntdebugging Blog |publisher=[[Microsoft]] |access-date=2011-03-16 |first=Dennis |last=Middleton |archive-url=https://web.archive.org/web/20110629043102/http://blogs.msdn.com/b/ntdebugging/archive/2008/05/20/understanding-ntfs-compression.aspx |archive-date=29 June 2011 |url-status=dead}}</ref><ref>{{cite web|url=https://www.forensicfocus.com/articles/shrinking-the-gap-carving-ntfs-compressed-files/|title=Shrinking the gap: carving NTFS-compressed files|access-date=2011-05-29}}</ref> Flash memory, such as [[SSD]] drives do not have the head movement delays and high [[Hard disk drive performance characteristics#Access time|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.<ref>{{cite web |url=https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc977213(v=technet.10) |title=Disk Concepts and Troubleshooting |date=11 September 2008 |work=[[Windows Resource Kit|Windows 2000 Server Resource Kit]] |publisher=Microsoft |access-date=2012-03-26 |at=Replacing the Boot Sector with the Emergency Repair Process}}</ref> Later versions of Windows do not allow important system files to be compressed.

=== System compression ===
{{anchor|CompactOS algorithms|CompactOS compression|CompactOS|WIMBoot}}
Since [[Windows 10]], Microsoft has introduced new file compression scheme based on the XPRESS algorithm with 4K/8K/16K block size<ref name=ms-xca>{{cite web | url=https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-xca/a8b7cb0a-92a6-4187-a23b-5e14273b96f8 | title=&#91;MS-XCA&#93;: Xpress Compression Algorithm | date=31 January 2023 }}</ref> and the [[LZX]] algorithm;<ref name=wmilib-compression>{{cite web |url=https://wimlib.net/compression.html |title=wimlib: the open source Windows Imaging (WIM) library – Compression algorithm}}</ref> both are variants of [[LZ77]] updated with [[Huffman encoding|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.<ref name=compactos>{{cite web |title=Compact OS, single-instancing, and image optimization |url=https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/compact-os |publisher=Microsoft |access-date=1 October 2019 |language=en-us}}</ref> CompactOS is not an extension of NTFS file compression and does not use the 'compressed' attribute; instead, it sets a [[NTFS reparse point#System compression|reparse point]] on each compressed file with a WOF (Windows Overlay Filter) tag,<ref name=oldnewthing-wof>{{cite web |author=Raymond Chen |url=https://devblogs.microsoft.com/oldnewthing/20190618-00/?p=102597 |title=What is WofCompressedData? Does WOF mean that Windows is a dog? |website=Microsoft DevBlogs| date=18 June 2019 }}</ref> but the actual data is stored in an alternate data stream named "WofCompressedData", which is decompressed on-the-fly by a WOF [[Installable File System|filesystem filter]] driver, and the main file is an empty [[sparse file]].<ref name=oldnewthing-wof/> This design is meant purely for read-only access, so any writes to compressed files result in an automatic decompression.<ref name=oldnewthing-wof/><ref>{{cite web |last=Biggers |first=Eric |title= NTFS-3G plugin for reading "system compressed" files |url=https://github.com/ebiggers/ntfs-3g-system-compression |website=GitHub |accessdate=1 October 2019 |date=29 April 2019}}</ref><ref>{{cite web |title=Re: [ntfs-3g-devel] Experimental support for Windows 10 "System Compressed" files |url=https://sourceforge.net/p/ntfs-3g/mailman/message/34481588/ |website=SourceForge.net |accessdate=1 October 2019}}</ref>

CompactOS compression is intended for [[OEM]]s who prepare OS images with the {{code|/compact}} flag of the [[DISM|{{code|DISM}} tool]] in [[Windows Assessment and Deployment Kit|Windows ADK]],<ref>{{cite web | url=https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/what-is-dism | title=DISM Overview | date=15 December 2021 }}</ref> but it can also be manually turned on per file with the {{code|/exe}} flag of the {{code|compact}} command.<ref name=compact-reference>{{cite web | url=https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/compact | title=Compact | date=3 February 2023 }}</ref> CompactOS algorithm avoids [[Fragmentation (computing)|file fragmentation]] by writing compressed data in contiguously allocated chunks, unlike core NTFS compression.{{Citation needed|date=October 2020}}

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 [[Windows Imaging Format|compressed WIM image]] on a separate hidden [[disk partition]].<ref name=wimboot>{{cite web |url=https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-8.1-and-8/dn594399(v=win.10) |title=Windows Image File Boot (WIMBoot) Overview|date=10 March 2015 }}</ref> Similarly to CompactOS, Windows system directories only contain [[sparse file]]s 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.<ref name=oldnewthing-wof/>

=== 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]].]]
[[File:One Petabyte of Files (Windows 10 Professional).png|thumb|One [[petabyte]] (1,125,899,906,842,624 bytes) of sparse files, 0 bytes on disk.]]

[[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; the file system maintains an internal list of such regions for each sparse file.<ref>{{cite web|title=Sparse Files|url=https://learn.microsoft.com/en-us/windows/win32/fileio/sparse-files|website=[[Microsoft Learn]]|publisher=[[Microsoft]]|access-date=25 January 2025|date=7 January 2021}}</ref> 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.<ref>{{cite web|last=Kandoth|first=Suresh B.|title=Sparse File Errors: 1450 or 665 due to file fragmentation: Fixes and Workarounds|url=http://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]]|access-date=21 October 2013|date=4 March 2009|archive-url=https://web.archive.org/web/20131021122654/http://blogs.msdn.com/b/psssql/archive/2009/03/04/sparse-file-errors-1450-or-665-due-to-file-fragmentation-fixes-and-workarounds.aspx|archive-date=21 October 2013|url-status=dead}}</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://learn.microsoft.com/en-us/windows/win32/fileio/sparse-files-and-disk-quota|website=[[Microsoft Learn]]|publisher=[[Microsoft]]|access-date=25 January 2025|date=15 August 2023}}</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.

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 name="techBlog2007" />

=== Transactions ===
As of Windows Vista, applications can use [[Transactional NTFS]] (TxF) to group multiple changes to files together into a single transaction. The transaction will guarantee that either all of the changes happen, or none of them do, and that no application outside the transaction will see the changes until they are committed.<ref>{{cite web|url=https://learn.microsoft.com/en-us/windows/win32/fileio/about-transactional-ntfs|title=About Transactional NTFS|website=[[Microsoft Learn]]|date=7 January 2021 |publisher=[[Microsoft]]|access-date=2025-01-25}}</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 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".<ref name=NTFS-TxF>{{cite web |title=Transactional NTFS (TxF)|url=https://learn.microsoft.com/en-us/windows/win32/fileio/transactional-ntfs-portal|website=[[Microsoft Learn]]|date=20 July 2022 |publisher=[[Microsoft]]|access-date=12 August 2023|ref=42}}</ref>

=== 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|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}}

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 [[NTFS symbolic link|symbolic link]]s, [[NTFS junction point|directory junction point]]s and [[NTFS volume mount point|volume mount point]]s. When the [[Object Manager (Windows)|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{{efn|name=date-limit|ntfs-3g interprets it as signed integer while ntfs3 as unsigned, though the latter seems more probable given that the signed value will either roll over into well [[Before Christ]] in the year 30828 if negative values are allowed, or become a de-facto 63-bit unsigned integer if only positive values are allowed, wasting the space for one bit. Given that NTFS is proprietary and largely only known through reverse-engineering, Microsoft has not publicly stated which is intended. [http://dubeyko.com/development/FileSystems/NTFS/ntfsdoc.pdf ntfsdoc.pdf] doesn't specify it either. But it won't make a difference until the year 30828 anyway.}} 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.<ref>{{cite web |url=https://blogs.msdn.microsoft.com/oldnewthing/20090306-00/?p=18913 |url-status=dead |title=Why is the Win32 epoch January 1, 1601? – The Old New Thing |archive-url=https://web.archive.org/web/20160817062401/https://blogs.msdn.microsoft.com/oldnewthing/20090306-00/?p=18913 |date=2009-03-06 |archive-date=2016-08-17 |author=Raymond Chen |access-date=2025-07-17 }}</ref>

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.<!-- Different from on FAT32 and exFAT, which has no constant granularity. -->

<ref name=ntfsdoc />

== Limitations ==

=== Resizing ===
Starting with [[Windows Vista]], Microsoft added the built-in ability to shrink or expand a partition. However, this ability does not relocate page file fragments or files that have been marked as unmovable, so shrinking a volume 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.

=== OneDrive ===
Since 2017, Microsoft requires the [[OneDrive]] file structure to reside on an NTFS disk.<ref>{{cite web |url=https://support.microsoft.com/en-us/office/unable-to-open-content-synced-in-a-onedrive-folder-on-an-external-drive-d38a7d5e-c099-4b72-8d84-3f62f2efc929 |title=Unable to open content synced in a OneDrive folder on an external drive |work=Microsoft Support |access-date=2021-04-03}}</ref> This is because OneDrive Files On-Demand feature uses NTFS reparse points to link files and folders that are stored in OneDrive to the local filesystem, making the file or folder unusable with any previous version of Windows, with any other NTFS file system driver, or any file system and backup utilities not updated to support it.<ref name=ntfs-3g>{{cite web |last1=André |first1=Jean-Pierre |title=NTFS-3G: Junction Points, Symbolic Links and Reparse Points |url=https://jp-andre.pagesperso-orange.fr/junctions.html |website=jp-andre.pagesperso-orange.fr |date=March 1, 2019 |archive-url=https://web.archive.org/web/20220828054508/https://jp-andre.pagesperso-orange.fr/junctions.html |archive-date=Aug 28, 2022 |url-status=dead}}</ref>

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

Internally, NTFS uses [[B-tree]]s to index file system data. A [[journaling file system|file system journal]] is used to guarantee the integrity of the file system metadata but not individual files' content. Systems using NTFS are known to have improved reliability compared to FAT file systems.<ref>{{cite web |title=Chapter 18 – Choosing a File System|url=https://learn.microsoft.com/en-us/previous-versions//cc750355(v=technet.10)|work=MS Windows NT Workstation 4.0 Resource Guide|date=20 February 2014 |publisher=[[Microsoft]]|access-date=25 January 2025}}</ref>

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

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

This boot partition format is roughly based upon the earlier [[File Allocation Table|FAT]] filesystem, but the fields are in different locations. Some of these fields, especially the "sectors per track", "number of heads" and "hidden sectors" fields may contain dummy values on drives where they either do not make sense or are not determinable.

The OS first looks at the 8 bytes at 0x30 to find the cluster number of the $MFT, then multiplies that number by the number of sectors per cluster (1 byte found at 0x0D). This value is the sector offset ([[Logical block addressing|LBA]]) to the $MFT, which is described below.

=== {{Anchor|MFT}} Master File Table === <!--'Master File Table' redirects here-->
In NTFS, all file, directory and [[#Metafiles|metafile]] data—file name, creation date, access permissions (by the use of [[access control list]]s), and size—are stored as metadata in the '''Master File Table'''<!--boldface per WP:R#PLA--> ('''MFT'''). This abstract approach allowed easy addition of file system features during Windows NT's development—an example is the addition of fields for indexing used by the [[Active Directory]] and the [[Windows Search]]. This also enables fast file search software to locate named local files and folders included in the MFT very quickly, without requiring any other index.

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

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

=== Metafiles ===
NTFS contains several files that define and organize the file system. In all respects, most of these files are structured like any other user file ($Volume being the most peculiar), but are not of direct interest to file system clients.<ref>{{cite web |url= http://www.cse.scu.edu/~tschwarz/coen252_07Fall/Lectures/NTFS.html |title= COEN 252 Computer Forensics NTFS |publisher= Faculty of Organization and Informatics University of Zagreb |last= Schwarz |first= Thomas |access-date=May 30, 2019|archive-url=https://web.archive.org/web/20210227190756/http://www.cse.scu.edu/~tschwarz/coen252_07Fall/Lectures/NTFS.html|archive-date=2021-02-27|url-status=dead}}</ref> These metafiles define files, back up critical file system data, buffer file system changes, manage free space allocation, satisfy [[BIOS]] expectations, track bad allocation units, and store security and disk space usage information. All content is in an unnamed data stream, unless otherwise indicated.

{| class="wikitable sortable plainrowheaders"
|+ MFT (entries 0–26 are the NTFS metafiles)
! scope="col" | Segment number
! scope="col" | File name
! scope="col" | Purpose
|-
! scope="row" | 0
| <code>$MFT</code>
| Describes all files on the volume, including file names, timestamps, stream names, and lists of cluster numbers where data streams reside, indexes, [[security identifier]]s, and file attributes like "read only", "compressed", "encrypted", etc.
|-
! scope="row" | 1
| <code>$MFTMirr</code>
| Duplicate of the first vital entries of {{mono|$MFT}}, usually 4 entries (4 [[kilobyte]]s).
|-
! scope="row" | 2
| <code>$LogFile</code>
| Contains transaction log of file system metadata changes.
|-
! scope="row" | 3
| <code>$Volume</code>
| Contains information about the volume, namely the volume object identifier, [[volume label]], file system version, and volume flags (mounted, chkdsk requested, requested {{mono|$LogFile}} resize, mounted on NT 4, volume serial number updating, structure upgrade request). This data is not stored in a data stream, but in special MFT attributes: If present, a volume object ID is stored in an {{mono|$OBJECT_ID}} record; the volume label is stored in a {{mono|$VOLUME_NAME}} record, and the remaining volume data is in a {{mono|$VOLUME_INFORMATION}} record. Note: volume serial number is stored in file {{mono|$Boot}} (below).
|-
! scope="row" | 4
| <code>$AttrDef</code>
| A table of MFT attributes that associates numeric identifiers with names.
|-
! scope="row" | 5
| <code>.</code>
| [[Root directory]]. Directory data is stored in {{mono|$INDEX_ROOT}} and {{mono|$INDEX_ALLOCATION}} attributes both named {{mono|$I30}}.
|-
! scope="row" | 6
| <code>$Bitmap</code>
| An array of bit entries: each bit indicates whether its corresponding cluster is used (allocated) or free (available for allocation).
|-
! scope="row" | 7
| <code>$Boot</code>
| [[Volume boot record]] (VBR). This file is always located at the first clusters on the volume. It contains [[Bootstrapping#Computing|bootstrap code]] (see [[NTLDR]]/[[Windows Boot Manager|BOOTMGR]]) and a [[BIOS parameter block]] including a [[volume serial number]] and cluster numbers of {{mono|$MFT}} and {{mono|$MFTMirr}}.
|-
! scope="row" | 8
| <code>$BadClus</code>
| A file that contains all the clusters marked as having [[bad sector]]s. This file simplifies cluster management by the chkdsk utility, both as a place to put newly discovered bad sectors, and for identifying unreferenced clusters. This file contains two data streams, even on volumes with no bad sectors: an unnamed stream contains bad sectors—it is zero length for perfect volumes; the second stream is named {{mono|$Bad}} and contains all clusters on the volume not in the first stream.
|-
! scope="row" | 9
| <code>$Secure</code>
| [[Access control list]] database that reduces overhead having many identical ACLs stored with each file, by uniquely storing these ACLs only in this database (contains two indices: {{mono|$SII}} ''(Standard_Information ID)'' and {{mono|$SDH}} ''([[Security Descriptor]] Hash)'', which index the stream named {{mono|$SDS}} containing actual ACL table).<ref name="insidewin2kntfs"/>
|-
! scope="row" | 10
| <code>$UpCase</code>
| A table of unicode uppercase characters for ensuring case-insensitivity in Win32 and DOS namespaces.
|-
! scope="row" | 11
| <code>$Extend</code>
| A file system directory containing various optional extensions, such as {{mono|$Quota}}, {{mono|$ObjId}}, {{mono|$Reparse}} or {{mono|$UsnJrnl}}.
|-
! scope="row" | 12–23
| colspan=2 |Reserved for {{mono|$MFT}} extension entries. Extension entries are additional MFT records that contain additional attributes that do not fit in the primary record. This could occur if the file is sufficiently fragmented, has many streams, long filenames, complex security, or other rare situations.
|-
! scope="row" | 24
| <code>$Extend\$Quota</code>
| Holds disk quota information. Contains two index roots, named {{mono|$O}} and {{mono|$Q}}.
|-
! scope="row" | 25
| <code>$Extend\$ObjId</code>
| Holds [[#Distributed Link Tracking (DLT)|link tracking]] information. Contains an index root and allocation named {{mono|$O}}.
|-
! scope="row" | 26
| <code>$Extend\$Reparse</code>
| Holds [[reparse point]] data (such as [[symbolic link]]s). Contains an index root and allocation named {{mono|$R}}.
|-
! scope="row" | 27–
| colspan=2 |Beginning of regular file entries.
|}

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

=== Attribute lists, attributes, and streams ===
For each file (or directory) described in the MFT record, there is a linear repository of stream descriptors (also named ''attributes''), packed together in one or more MFT records (containing the so-called ''attributes list''), with extra padding to fill the fixed 1&nbsp;KB size of every MFT record, and that fully describes the effective streams associated with that file.

Each attribute has an attribute type (a fixed-size integer mapping to an attribute definition in file {{mono|$AttrDef}}), an optional attribute name (for example, used as the name for an alternate data stream), and a value, represented in a sequence of bytes. For NTFS, the standard data of files, the alternate data streams, or the index data for directories are stored as attributes.

According to {{mono|$AttrDef}}, some attributes can be either resident or non-resident. The {{mono|$DATA}} attribute, which contains file data, is such an example. When the attribute is resident (which is represented by a flag), its value is stored directly in the MFT record. Otherwise, clusters are allocated for the data, and the cluster location information is stored as data runs in the attribute.
* For each file in the MFT, the attributes identified by ''attribute type, attribute name'' must be unique. Additionally, NTFS has some ordering constraints for these attributes.
* There is a predefined null attribute type, used to indicate the end of the list of attributes in one MFT record. It must be present as the last attribute in the record (all other storage space available after it will be ignored and just consists of padding bytes to match the record size in the MFT).
* Some attribute types are required and must be present in each MFT record, except unused records that are just indicated by null attribute types.
** This is the case for the {{mono|$STANDARD_INFORMATION}} attribute that is stored as a fixed-size record and contains the [[timestamp]]s and other basic single-bit attributes (compatible with those managed by [[File Allocation Table|FAT]] in DOS or [[Windows 9x]]).
* Some attribute types cannot have a name and must remain anonymous.
** This is the case for the standard attributes, or for the preferred NTFS "filename" attribute type, or the "short filename" attribute type, when it is also present (for compatibility with DOS-like applications, see below). It is also possible for a file to contain only a short filename, in which case it will be the preferred one, as listed in the Windows Explorer.
** The filename attributes stored in the attribute list do not make the file immediately accessible through the [[hierarchical file system]]. In fact, all the filenames must be indexed separately in at least one other directory on the same volume. There it must have its own MFT record and its own [[security descriptor]]s and attributes that reference the MFT record number for this file. This allows the same file or directory to be "hardlinked" several times from several containers on the same volume, possibly with distinct filenames.
* The default data stream of a regular file is a stream of type {{mono|$DATA}} but with an anonymous name, and the ADSs are similar but must be named.
* On the other hand, the default data stream of directories has a distinct type, but are not anonymous: they have an attribute name ("{{mono|$I30}}" in NTFS 3+) that reflects its indexing format.

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

Windows system calls may handle alternate data streams.<ref name="How NTFS Works"/> Depending on the operating system, utility and remote file system, a file transfer might silently strip data streams.<ref name="How NTFS Works"/> A safe way of copying or moving files is to use the BackupRead and BackupWrite system calls, which allow programs to enumerate streams, to verify whether each stream should be written to the destination volume and to knowingly skip unwanted streams.<ref name="How NTFS Works"/>

=== Resident vs. non-resident attributes ===
To optimize the storage and reduce the I/O overhead for the very common case of attributes with very small associated value, NTFS prefers to place the value within the attribute itself (if the size of the attribute does not then exceed the maximum size of an MFT record), instead of using the MFT record space to list clusters containing the data; in that case, the attribute will not store the data directly but will just store an allocation map (in the form of ''data runs'') pointing to the actual data stored elsewhere on the volume.<ref>{{cite web|url=http://blogs.technet.com/b/askcore/archive/2009/10/16/the-four-stages-of-ntfs-file-growth.aspx|title=The Four Stages of NTFS File Growth|access-date=22 September 2018|archive-url=https://web.archive.org/web/20180923052803/https://blogs.technet.microsoft.com/askcore/2009/10/16/the-four-stages-of-ntfs-file-growth/|archive-date=23 September 2018|url-status=dead}}</ref> When the value can be accessed directly from within the attribute, it is called "resident data" (by [[computer forensics]] workers). The amount of data that fits is highly dependent on the file's characteristics, but 700 to 800 bytes is common in single-stream files with non-lengthy filenames and no ACLs.
* Some attributes (such as the preferred filename, the basic file attributes) cannot be made non-resident. For non-resident attributes, their allocation map must fit within MFT records.
* Encrypted-by-NTFS, sparse data streams, or compressed data streams cannot be made resident.
* The format of the allocation map for non-resident attributes depends on its capability of supporting sparse data storage. In the current implementation of NTFS, once a non-resident data stream has been marked and converted as sparse, it cannot be changed back to non-sparse data, so it cannot become resident again, unless this data is fully truncated, discarding the sparse allocation map completely.
* When a non-resident attribute is so fragmented that its effective allocation map cannot fit entirely within one MFT record, NTFS stores the attribute in multiple records. The first one among them is called the base record, while the others are called extension records. NTFS creates a special attribute {{mono|$ATTRIBUTE_LIST}} to store information mapping different parts of the long attribute to the MFT records, which means the allocation map may be split into multiple records. The {{mono|$ATTRIBUTE_LIST}} itself can also be non-resident, but its own allocation map must fit within one MFT record.
* When there are too many attributes for a file (including ADS's, extended attributes, or [[security descriptor]]s), so that they cannot fit all within the MFT record, extension records may also be used to store the other attributes, using the same format as the one used in the base MFT record, but without the space constraints of one MFT record.

The allocation map is stored in a form of ''data runs'' with compressed encoding. Each data run represents a contiguous group of clusters that store the attribute value. For files on a multi-GB volume, each entry can be encoded as 5 to 7 bytes, which means a {{val|1|ul=KB}} MFT record can store about 100 such data runs. However, as the {{mono|$ATTRIBUTE_LIST}} also has a size limit, it is dangerous to have more than 1 million fragments of a single file on an NTFS volume, which also implies that it is in general not a good idea to use NTFS compression on a file larger than {{val|10|ul=GB}}.<ref>{{cite web |url=https://support.microsoft.com/en-us/topic/a-heavily-fragmented-file-in-an-ntfs-volume-may-not-grow-beyond-a-certain-size-da1c0dfd-a5a1-90b4-4bf7-b65b13ef9d35 |title=A heavily fragmented file in an NTFS volume may not grow beyond a certain size |access-date=2021-05-19 |url-status=live |archive-url=https://web.archive.org/web/20210506185845/https://support.microsoft.com/en-us/topic/a-heavily-fragmented-file-in-an-ntfs-volume-may-not-grow-beyond-a-certain-size-da1c0dfd-a5a1-90b4-4bf7-b65b13ef9d35 |archive-date=2021-05-06}}</ref>

The NTFS file system driver will sometimes attempt to relocate the data of some of the attributes that can be made non-resident into the clusters, and will also attempt to relocate the data stored in clusters back to the attribute inside the MFT record, based on priority and preferred ordering rules, and size constraints.

Since resident files do not directly occupy clusters ("allocation units"), it is possible for an NTFS volume to contain more files on a volume than there are clusters. For example, a {{val|74.5|u=GB}} partition NTFS formats with 19,543,064 clusters of {{val|4|u=KB}}. Subtracting system files (a {{val|64|ul=MB}} log file, a 2,442,888-byte Bitmap file, and about 25 clusters of fixed overhead) leaves 19,526,158 clusters free for files and indices. Since there are four MFT records per cluster, this volume theoretically could hold almost 4 × 19,526,158 = 78,104,632 resident files.

=== Opportunistic locks ===
Opportunistic file locks (oplocks) allow clients to alter their buffering strategy for a given file or stream in order to increase performance and reduce network use.<ref>{{cite web |url=http://msdn.microsoft.com/en-us/library/cc308442.aspx |title=How Oplocks function in the Windows Environment: Overview |access-date=2018-12-19 |url-status=dead |archive-url=https://web.archive.org/web/20100823125612/http://msdn.microsoft.com/en-us/library/cc308442.aspx |archive-date=2010-08-23}}</ref> Oplocks apply to the given open stream of a file and do not affect oplocks on a different stream.

Oplocks can be used to transparently access files in the background. A network client may avoid writing information into a file on a remote server if no other process is accessing the data, or it may buffer read-ahead data if no other process is writing data.

Windows supports four different types of oplocks:
* Level 2 (or shared) oplock: multiple readers, no writers (i.e. read caching).
* Level 1 (or exclusive) oplock: exclusive access with arbitrary buffering (i.e. read and write caching).
* Batch oplock (also exclusive): a stream is opened on the server, but closed on the client machine (i.e. read, write and handle caching).
* Filter oplock (also exclusive): applications and file system filters can "back out" when others try to access the same stream (i.e. read and write caching) (since Windows 2000)

Opportunistic locks have been enhanced in Windows 7 and Windows Server 2008 R2 with per-client oplock keys.<ref>{{cite web|url=https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff383236(v=ws.10)|title=What's New in NTFS|website=[[Microsoft Learn]]|date=2 July 2012 |access-date=25 January 2025}}</ref>

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

For historical reasons, the versions of Windows that do not support NTFS all keep time internally as local zone time, and therefore so does the [[File Allocation Table|FAT]] file system. This means that when files are copied or moved between NTFS and FAT partitions, the OS needs to convert timestamps on the fly. But if some files are moved when [[daylight saving time]] (DST) is in effect, and other files are moved when [[standard time]] is in effect, there can be some ambiguities in the conversions. As a result, especially shortly after one of the days on which local zone time changes, users may observe that some files have timestamps that are incorrect by one hour. Due to the differences in implementation of DST in different jurisdictions, this can result in a potential timestamp error of up to 4&nbsp;hours in any given 12&nbsp;months.<ref>{{cite web |url=https://www.codeproject.com/Articles/1144/Beating-the-Daylight-Savings-Time-Bug-and-Getting |title=Beating the Daylight Saving Time bug and getting correct file modification times |first=Jonathan |last=Gilligan |date=28 May 2001 |website=The Code Project}}</ref>

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

==See also==
* [[Comparison of file systems]]
* [[NTFSDOS]]
* [[ntfsresize]]
* [[WinFS]] (a canceled Microsoft filesystem)
* [[ReFS]], a newer Microsoft filesystem

==Notes==
{{Notelist}}

==References==
{{Reflist}}

==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://www.microsoft.com/en-us/research/publication/single-instance-storage-in-windows-2000/ |title=Single Instance Storage in Windows 2000 |journal=Proceedings of 4th USENIX Windows Systems Symposium |date=January 2000}}
* {{cite book |last= Custer |first= Helen |title= Inside the Windows NT File System |year= 1994 |publisher= [[Microsoft Press]] |isbn= 978-1-55615-660-1 |url= https://archive.org/details/insidewindowsntf00cust }}
* {{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 |url= https://archive.org/details/windowsntfilesys00naga }}
* {{Cite web |url=https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc758691(v=ws.10) |title= NTFS Technical Reference |website=[[Microsoft Learn]] |publisher=[[Microsoft]] |date=8 October 2009}}
{{Refend}}

==External links==
* [https://www.kernel.org/doc/html/latest/filesystems/ntfs3.html NTFS3]
* [https://www.paragon-software.com/home/ntfs3-driver-faq/ NTFS3 source code]

{{Microsoft Windows components}}
{{File systems}}

[[Category:Compression file systems]]
[[Category:File systems supported by the Linux kernel]]
[[Category:Windows disk file systems]]
[[Category:1993 software]]