Editing NTFS (section)

== 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"
!Windows Version
!{{mono|$LogFile}} format version
|-
|{{rh}}|[[Windows NT 4.0]]
|rowspan="5"|1.1
|-
|{{rh}}|[[Windows 2000]]
|-
|{{rh}}|[[Windows XP]]
|-
|{{rh}}|[[Windows Vista]]
|-
|{{rh}}|[[Windows 7]]
|-
|{{rh}}|[[Windows 8]]
|rowspan="3"|2.0
|-
|{{rh}}|[[Windows 8.1]]
|-
|{{rh}}|[[Windows 10]]
|}

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) you will also receive this cached information, in addition to the name and inode. However, you 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. You can always obtain up-to-date data using GetFileInformationByHandle (which is the true equivalent of POSIX stat 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.

If system files that are needed at boot time (such as drivers, NTLDR, winload.exe, or BOOTMGR) are compressed, the system may fail to boot correctly, because decompression filters are not yet loaded.<ref>{{cite web |url=https://technet.microsoft.com/en-us/library/cc977213.aspx |title=Disk Concepts and Troubleshooting |date=11 September 2008 |publisher=Microsoft |access-date=2012-03-26}}</ref>{{failed verification|date=May 2022}} Later editions of Windows{{which|date=January 2016}} 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.