NTFS
NTFS is a proprietary journaling file system developed by Microsoft. Starting with Windows NT 3.1, it is the default file system of the Windows NT family.
NTFS has several technical improvements over the file systems that it superseded – File Allocation Table and High Performance File System – such as improved support for metadata and advanced data structures to improve performance, reliability, and disk space use. Additional extensions are a more elaborate security system based on access control lists and file system journaling.
NTFS is supported in other desktop and server operating systems as well. Linux and BSD have a free and open-source NTFS driver, called NTFS-3G, with both read and write functionality. macOS comes with read-only support for NTFS; its write support for NTFS is unstable, so by default file writing is disabled.
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 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 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. The original NTFS developers were Tom Miller, Gary Kimura, Brian Andrew, and David Goebel.
Probably as a result of this common ancestry, HPFS and NTFS use the same disk partition identification type code. 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. 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:| NTFS version number | First operating system | Release date | New features | Remarks |
| 1.0 | Windows NT 3.1 | 1993 | 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 is installed. |
| 1.1 | Windows NT 3.51 | 1995 | Compressed files, named streams and access control lists | |
| 1.2 | Windows NT 4.0 | 1996 | Security descriptors | Commonly called NTFS 4.0 after the OS release. |
| 3.0 | Windows 2000 | 2000 | Disk quotas, Encrypting File System, sparse files, reparse points, update sequence number journaling, the $Extend 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. |
| 3.1 | Windows XP | October 2001 | Expanded the Master File Table entries with redundant [|MFT] record number | Commonly called NTFS 5.1 after the OS release. |
The version number is based on the operating system version; it should not be confused with the NTFS version number.
Although subsequent versions of Windows added new file system-related features, they did not change NTFS itself. For example, Windows Vista implemented NTFS symbolic links, Transactional NTFS, partition shrinking, and self-healing. 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.
Features
NTFS v3.0 includes several new features over its predecessors: sparse file support, disk use quotas, reparse points, distributed link tracking, and file-level encryption called the Encrypting File System.Scalability
NTFS is optimized for 4 KB clusters, but supports a maximum cluster size of 2MB. The maximum NTFS volume size that the specification can support is clusters, but not all implementations achieve this theoretical maximum, as discussed below.The maximum NTFS volume size implemented in Windows XP Professional is clusters, partly due to partition table limitations. For example, using 64KB clusters, the maximum size Windows XP NTFS volume is 256TB minus 64KB. Using the default cluster size of 4KB, the maximum NTFS volume size is 16TB minus 4KB. Both of these are vastly higher than the 128GB limit in Windows XP SP1. Because partition tables on master boot record disks support only partition sizes up to 2TB, multiple GUID Partition Table volumes must be combined to create a single NTFS volume larger than 2TB. Booting from a GPT volume to a Windows environment in a Microsoft supported way requires a system with Unified Extensible Firmware Interface and 64-bit support.
The NTFS maximum theoretical limit on the size of individual files is 16EiB minus 1KB, 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 8PB minus 2MB or 9,007,199,252,643,840 bytes.
Journaling
NTFS is a journaling file system and uses the NTFS Log to record metadata changes to the volume. It is a feature that FAT does not provide and critical for NTFS to ensure that its complex internal data structures will remain consistent in case of system crashes or data moves performed by the defragmentation API, and allow easy rollback of uncommitted changes to these critical data structures when the volume is remounted. Notably affected structures are the volume allocation bitmap, modifications to MFT records such as moves of some variable-length attributes stored in MFT records and attribute lists, and indices for directories and security descriptors.The format has evolved through several versions:
| Windows Version | $LogFile format version |
| Windows NT 4.0 | 1.1 |
| Windows 2000 | 1.1 |
| Windows XP | 1.1 |
| Windows Vista | 1.1 |
| Windows 7 | 1.1 |
| Windows 8 | 1.1 |
| Windows 8.1 | 2.0 |
| Windows 10 | 2.0 |
The incompatibility of the $LogFile versions implemented by Windows 8.1 and Windows 10 prevents Windows 8 from correctly processing the $LogFile in case the NTFS volume is left in the dirty state by an abrupt shutdown or by hibernating to disk in the logoff state. This inability to process the v2.0 of the $LogFile on dirty volumes by these earlier versions of Windows results in invocation of the CHKDSK disk repair utility when dual-booting Windows 10 with these older systems. A Windows Registry setting exists to prevent the automatic upgrade of the $LogFile to the newer version.
The USN Journal is a system management feature that records changes to files, streams and directories on the volume, as well as their various attributes and security settings. The journal is made available for applications to track changes to the volume. This journal can be enabled or disabled on non-system volumes.
Hard links
The hard link feature allows different file names to directly refer to the same file contents. Hard links are similar to directory junctions, but refer to files instead. Hard links may link only to files in the same volume, because each volume has its own MFT. Hard links have their own file metadata, so a change in file size or attributes under one hard link may not update the others until they are opened. Hard links were originally included to support the POSIX subsystem in Windows NT.Windows uses hard links to support short filenames in NTFS. Operating system support is needed because there are legacy applications that can work only with 8.3 filenames. In this case, an additional filename record and directory entry is added, but both 8.3 and long file name are linked and updated together, unlike a regular hard link.
The NTFS file system has a limit of 1024 hard links on a file.
Alternate data streams (ADS)
Alternate data streams allow more than one data stream to be associated with a filename, using the format "filename:streamname".NTFS Streams were introduced in Windows NT 3.1, to enable Services for Macintosh to store resource forks. Although current versions of Windows Server no longer include SFM, third-party Apple Filing Protocol products still use this feature of the file system. Very small ADS are added by Internet Explorer and recently by other browsers to mark files downloaded from external sites as possibly unsafe to run; the local shell would then require user confirmation before opening them. When the user indicates that they no longer want this confirmation dialog, this ADS is deleted.
Alternate streams are not listed in Windows Explorer, and their size is not included in the file's size. 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 tool called Streams to view streams on a selected volume. Starting with Windows PowerShell 3.0, it is possible to manage ADS natively with six cmdlets: Add-Content, Clear-Content, Get-Content, Get-Item, Remove-Item, Set-Content.
Malware has used alternate data streams to hide code. As a result, malware scanners and other special tools now check for alternate data streams.
File compression
NTFS can compress files using LZNT1 algorithm Files are compressed in 16 cluster chunks. With 4 KB clusters, files are compressed in 64 KB chunks. The compression algorithms in NTFS are designed to support cluster sizes of up to 4 KB. When the cluster size is greater than 4 KB on an NTFS volume, NTFS compression is not available. If the compression reduces 64KB of data to 60KB or less, NTFS treats the unneeded 4KB pages like empty sparse file clusters—they are not written. This allows for reasonable random-access times as the OS just has to follow the chain of fragments.However, large compressible files become highly fragmented since every chunk smaller than 64KB becomes a fragment. According to research by Microsoft's NTFS Development team, 50–60GB is a reasonable maximum size for a compressed file on an NTFS volume with a 4KB cluster size. This reasonable maximum size decreases sharply for volumes with smaller cluster sizes. Single-user systems with limited hard disk space can benefit from NTFS compression for small files, from 4KB to 64KB or more, depending on compressibility. Files smaller than approximately 900 bytes are stored within the directory entry of the MFT.
Flash memory, such as SSD drives do not have the head movement delays of hard disk drives, so fragmentation has only a smaller penalty. Users of fast multi-core processors will find improvements in application speed by compressing their applications and data as well as a reduction in space used. Note that SSDs with Sandforce controllers already compress data. However, since less data is transferred, there is a reduction in I/Os.
Compression works best with files that have repetitive content, are seldom written, are usually accessed sequentially, and are not themselves compressed. Log files are an ideal example.
If system files that are needed at boot time are compressed, the system may fail to boot correctly, because decompression filters are not yet loaded. Later editions of Windows do not allow important system files to be compressed.
Files may be compressed or decompressed individually for a drive, directory, or directory tree, becoming a default for the files inside.
Although read–write access to compressed files is transparent, Microsoft recommends avoiding compression on server systems and/or network shares holding roaming profiles, because it puts a considerable load on the processor.
CompactOS algorithms
Since Windows 10, Microsoft has introduced additional algorithms, namely XPRESS4K/8K/16K and LZX. Both algorithms are based on LZ77 with Huffman entropy coding, which LZNT1 lacked. These algorithms were taken from the Windows Imaging Format. They are mainly used for new CompactOS feature, which compresses the entire system partition using one of these algorithms. They can also be manually turned on per file with the flag of the command.Microsoft did not change the NTFS specification to introduce these new features. It rather chose to use a reparse point on the file with tag 0x80000017 to record the fact that the file has been specially compressed, and the actual data is stored in an alternate data stream named "WofCompressedData". The new design is meant purely for read-only access, so any writes to compressed files result in fully decompressing the file on Windows.
Sparse files
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. A sparse file does not necessarily include sparse zeros areas; the "sparse file" attribute just means that the file is allowed to have them.Database applications, for instance, may use sparse files. As with compressed files, the actual sizes of sparse files are not taken into account when determining quota limits.
Volume Shadow Copy
The Volume Shadow Copy Service keeps historical versions of files and folders on NTFS volumes by copying old, newly overwritten data to shadow copy via copy-on-write technique. The user may later request an earlier version to be recovered. This also allows data backup programs to archive files currently in use by the file system. On heavily loaded systems, Microsoft recommends setting up a shadow copy volume on a separate disk.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.
Transactions
As of Windows Vista, applications can use Transactional NTFS 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.It uses similar techniques as those used for Volume Shadow Copies to ensure that overwritten data can be safely rolled back, and a CLFS log to mark the transactions that have still not been committed, or those that have been committed but still not fully applied.
Transactional NTFS does not restrict transactions to just the local NTFS volume, but also includes other transactional data or operations in other locations such as data stored in separate volumes, the local registry, or SQL databases, or the current states of system services or remote services. These transactions are coordinated network-wide with all participants using a specific service, the DTC, to ensure that all participants will receive same commit state, and to transport the changes that have been validated by any participant. 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".
Security
In NTFS, each file or folder is assigned a security descriptor that defines its owner and contains two access control lists. The first ACL, called discretionary access control list, defines exactly what type of interactions are allowed or forbidden by which user or groups of users. For example, files in the folder may be read and executed by all users but modified only by a user holding administrative privileges. 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, 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 he or she succeeds.
Encryption
provides strong and user-transparent encryption of any file or folder on an NTFS volume. EFS works in conjunction with the EFS service, Microsoft's CryptoAPI and the EFS File System Run-Time Library. EFS works by encrypting a file with a bulk symmetric key, 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 cipher is used. The symmetric key that is used to encrypt the file is then encrypted with a public key that is associated with the user who encrypted the file, and this encrypted data is stored in an alternate data stream of the encrypted file. To decrypt the file, the file system uses the private key of the user to decrypt the symmetric key that is stored in the file header. It then uses the symmetric key to decrypt the file. Because this is done at the file system level, it is transparent to the user. Also, in case of a user losing access to their key, support for additional decryption keys has been built into the EFS system, so that a recovery agent can still access the files if needed. NTFS-provided encryption and NTFS-provided compression are mutually exclusive; however, NTFS can be used for one and a third-party tool for the other.The support of EFS is not available in Basic, Home, and MediaCenter versions of Windows, and must be activated after installation of Professional, Ultimate, and Server versions of Windows or by using enterprise deployment tools within Windows domains.
Quotas
s were introduced in NTFS v3. They allow the administrator of a computer that runs a version of Windows that supports NTFS to set a threshold of disk space that users may use. It also allows administrators to keep track of how much disk space each user is using. An administrator may specify a certain level of disk space that a user may use before they receive a warning, and then deny access to the user once they hit their upper limit of space. Disk quotas do not take into account NTFS's transparent file-compression, should this be enabled. Applications that query the amount of free space will also see the amount of free space left to the user who has a quota applied to them.Reparse points
Introduced in NTFS v3, NTFS reparse points are used by associating a reparse tag in the user space attribute of a file or directory. Microsoft includes several default tags including symbolic links, directory junction points and volume mount points. When the Object Manager parses a file system name lookup and encounters a reparse attribute, it will reparse the name lookup, passing the user controlled reparse data to every file system filter driver that is loaded into Windows. Each filter driver examines the reparse data to see whether it is associated with that reparse point, and if that filter driver determines a match, then it intercepts the file system request and performs its special functionality.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 page file, the index of Windows Search, and any [|Shadow Copy] used by System Restore. Various third-party tools are capable of resizing NTFS partitions.Internals
Internally, NTFS uses B-trees to index file system data. A 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.NTFS allows any sequence of 16-bit values for name encoding except 0x0000. This means UTF-16 code units are supported, but the file system does not check whether a sequence is valid UTF-16. 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
$MFT, $MFTMirr, $LogFile, $Volume, $AttrDef, ., $Bitmap, $Boot, $BadClus, $Secure, $UpCase, and $Extend. . and $Extend are both directories; the others are files. The NT kernel limits full paths to 32,767 UTF-16 code units. There are some additional restrictions on code points and file names.Partition Boot Sector (VBR)
This boot partition format is roughly based upon the earlier 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. This value is the sector offset to the $MFT, which is described below.
Master File Table
In NTFS, all file, directory and metafile data—file name, creation date, access permissions, and size—are stored as metadata in the Master File Table. This abstract approach allowed easy addition of file system features during Windows NT's development—an example is the addition of fields for indexing used by the Active Directory software. This also enables fast file search software 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 disk fragmentation. A directory entry consists of a filename and a "file ID", which is the record number representing the file in the Master File Table. The file ID also contains a reuse count to detect stale references. While this strongly resembles the W_FID of Files-11, other NTFS structures radically differ.
Two copies of the MFT are stored in case of corruption. If the first record is corrupted, NTFS reads the second record to find the MFT mirror file. Locations for both files are stored in the boot sector.
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, but are not of direct interest to file system clients. These metafiles define files, back up critical file system data, buffer file system changes, manage free space allocation, satisfy BIOS expectations, track bad allocation units, and store security and disk space usage information. All content is in an unnamed data stream, unless otherwise indicated.These metafiles are treated specially by Windows, handled directly by the
NTFS.SYS driver and are difficult to directly view: special purpose-built tools are needed. 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 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: nfi.exe c:\$MFT Another way to bypass the restriction is to use 7-Zip's file manager and go to the low-level NTFS path \\.\X:\. Here, 3 new folders will appear: $EXTEND, Attribute lists, attributes, and streams
For each file described in the MFT record, there is a linear repository of stream descriptors, packed together in one or more MFT records, with extra padding to fill the fixed 1 KB size of every MFT record, and that fully describes the effective streams associated with that file.Each attribute has an attribute type, an optional attribute name, and a value, represented in a sequence of bytes. For NTFS, the standard data of files, the alternate data streams, or the index data for directories are stored as attributes.
According to $AttrDef, some attributes can be either resident or non-resident. The $DATA attribute, which contains file data, is such an example. When the attribute is resident, 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.
- 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 $STANDARD_INFORMATION attribute that is stored as a fixed-size record and contains the timestamps and other basic single-bit attributes.
- 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. 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 descriptors 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 $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 that reflects its indexing format.
Windows system calls may handle alternate data streams. Depending on the operating system, utility and remote file system, a file transfer might silently strip data streams. 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.
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, 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 pointing to the actual data stored elsewhere on the volume. When the value can be accessed directly from within the attribute, it is called "resident data". 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 cannot be made non-resident. For non-resident attributes, their allocation map must fit within MFT records.
- Encrypted-by-NTFS, sparse data streams, or compressed data streams cannot be made resident.
- The format of the allocation map for non-resident attributes depends on its capability of supporting sparse data storage. In the current implementation of NTFS, once a non-resident data stream has been marked and converted as sparse, it cannot be changed back to non-sparse data, so it cannot become resident again, unless this data is fully truncated, discarding the sparse allocation map completely.
- When a non-resident attribute is so fragmented, that its effective allocation map cannot fit entirely within one MFT record, NTFS stores the attribute in multiple records. The first one among them is called the base record, while the others are called extension records. NTFS creates a special attribute $ATTRIBUTE_LIST to store information mapping different parts of the long attribute to the MFT records, which means the allocation map may be split into multiple records. The $ATTRIBUTE_LIST itself can also be non-resident, but its own allocation map must fit within one MFT record.
- When there are too many attributes for a file, 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 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, it is possible for an NTFS volume to contain more files on a volume than there are clusters. For example, a 74.5GB partition NTFS formats with 19,543,064 clusters of 4KB. Subtracting system files 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 allow clients to alter their buffering strategy for a given file or stream in order to increase performance and reduce network use. 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 oplock: multiple readers, no writers.
- Level 1 oplock: exclusive access with arbitrary buffering.
- Batch oplock : a stream is opened on the server, but closed on the client machine.
- Filter oplock : applications and file system filters can "back out" when others try to access the same stream
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.For historical reasons, the versions of Windows that do not support NTFS all keep time internally as local zone time, and therefore so do all file systems – other than NTFS – that are supported by current versions of Windows. This means that when files are copied or moved between NTFS and non-NTFS partitions, the OS needs to convert timestamps on the fly. But if some files are moved when daylight saving time is in effect, and other files are moved when standard time is in effect, there can be some ambiguities in the conversions. As a result, especially shortly after one of the days on which local zone time changes, users may observe that some files have timestamps that are incorrect by one hour. Due to the differences in implementation of DST in different jurisdictions, this can result in a potential timestamp error of up to 4 hours in any given 12 months.
Interoperability
While the different NTFS versions are for the most part fully forward- and backward-compatible, there are technical considerations for mounting newer NTFS volumes in older versions of Microsoft Windows. This affects dual-booting, and external portable hard drives. For example, attempting to use an NTFS partition with "Previous Versions" on an operating system that does not support it will result in the contents of those previous versions being lost. A Windows command-line utility called convert.exe can convert supporting file systems to NTFS, including HPFS, FAT16 and FAT32.As of Windows 10 version 1709, known as the Fall Creators Update, Microsoft requires the OneDrive file structure to reside on an NTFS disk. This is because the reparse tag on every file and directory within the local OneDrive file structure is set in a recursive manner, thus 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. It is unknown whether recursive linking is a feature of the NTFS file system or an undocumented workaround by Microsoft to support OneDrive's new "Files On-Demand" feature.
Implementations
3.2 released in May 1999 included read-only NTFS support written by Semen Ustimenko. This implementation was ported to NetBSD by Christos Zoulas and Jaromir Dolecek and released with NetBSD 1.5 in December 2000. 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 version 4.9 released 1 May 2011.Linux kernel versions 2.2.0 and later include the ability to read NTFS partitions; kernel versions 2.6.0 and later contain a driver written by Anton Altaparmakov and Richard Russon which supports file read, overwrite and resize. Due to the complexity of internal NTFS structures the built-in 2.6.14 kernel driver disallows changes to the volume that are considered unsafe, to avoid corruption.
Mac OS X 10.3 included Ustimenko's read-only implementation of NTFS from FreeBSD. Then Apple hired Anton Altaparmakov to write a new NTFS implementation for Mac OS X 10.6. Native NTFS write support has been discovered 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 panics", probably the reason why write support has not been enabled or advertised.
Captive NTFS, a 'wrapping' driver that uses Windows' own driver ntfs.sys, exists for Linux. It was built as a Filesystem in Userspace program and released under the GPL but work on Captive NTFS ceased in 2006.
NTFS-3G is a free GPL-licensed 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, Solaris, QNX and Haiku 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.
Paragon Software Group sells a read-write driver named NTFS for Mac OS X, which is also included on some models of Seagate hard drives.
eComStation offers a read-only NTFS support. There is a beta NTFS driver that allows write/delete for eComStation, but is generally considered unsafe.
There is a free-for-personal-use read/write driver for MS-DOS by Avira called "NTFS4DOS".
Ahead Software developed a "NTFSREAD" driver for DR-DOS 7.0x between 2002 and 2004. It was part of their Nero Burning ROM software.