NTFS

NTFS

Developer(s)	Microsoft
Full name	NT File System
Introduced	July 1993 with Windows NT 3.1
Partition IDs	0x07 (MBR) EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (GPT)
Structures
Directory contents	[[B+++3903284039284320948309248203984984735983732874238974238974239874293874238974289374023984903485837589237475972307438974230483894572038439875340753498759348759384759843758943759034759843759843758347549838590348590384-23849032843894759475943574397584vn4u3cn9834bv948y3nc934yn5y34cq9-8ny349vyn94-3yc593-48yn5c943-yv9348ybv59438yn349nc943ync9yn5c98y4ncnq34vpn3498nvp9834nc98nyc9pnyp9nc5p94vn984cny9p3ncy39cn984cn98vn89n5v4p98vnn4ypc9pm34cuq349pnc5u45nc943y5vn439yvb4398yvb8934vy8934yv59834yv8934ybv8934byv8934yc98n3498pmyx3849ync98qy5c98q3yvc89anu83uq4nc89nq3[cun4839v[n43c983n4c[05nu43cn40[3cu034uc5043nc0943nuc5034nv[08qunc[89ernuvruencpuercipuerncouer[c80unq[8034n9c[439ncu[4308nuc[nq03u4cm5[43unc5q30[4cu[3048nuc3qn4c[u tree]]
File allocation	Linked List
Bad blocks	$badclus
Limits
Max volume size	264 − 1 clusters
Max file size	264 bytes (16 EiB) minus 1 KiB
Max no. of files	4,294,967,295 (232-1)
Max filename length	255 UTF-16 code units
Allowed filename characters	In Posix namespace, any UTF-16 code unit (case sensitive) except U+0000 (NUL) and / (slash). In Win32 namespace, any UTF-16 code unit (case insensitive) except U+0000 (NUL) / (slash) \ (backslash) : (colon) * (asterisk) ? (Question mark) " (quote) < (less than) > (greater than) and | (pipe)
Features
Dates recorded	Creation, modification, POSIX change, access
Date range	1 January 1601 – 28 May 60056 (File times are 64-bit numbers counting 100-nanosecond intervals (ten million per second) since 1601, which is 58,000+ years)
Date resolution	100ns
Forks	Yes (see Alternate data streams below)
Attributes	Read-only, hidden, system, archive, not content indexed, off-line, temporary, compressed
File system permissions	ACLs
Transparent compression	Per-file, LZ77 (Windows NT 3.51 onward)
Transparent encryption	Per-file, DESX (Windows 2000 onward), Triple DES (Windows XP onward), AES (Windows XP Service Pack 1, Windows Server 2003 onward)
Data deduplication	Yes
Other
Supported operating systems	Windows NT family (Windows NT 3.1 to Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7)

NTFS is the standard file system of Windows NT, including its later versions Windows 2000, Windows XP, Windows Server 2003, Windows Server 2008, Windows Vista, and Windows 7.

NTFS supersedes the FAT file system as the preferred file system for Microsoft’s Windows operating systems. NTFS has several improvements over FAT and HPFS (High Performance File System) such as improved support for metadata and the use of advanced data structures to improve performance, reliability, and disk space utilization, plus additional extensions such as security access control lists (ACL) and file system journaling. The file system specification is a trade secret, although it can be licensed commercially from Microsoft through their Intellectual Property licensing program.

History

In the mid 1980s Microsoft and IBM formed a joint project to create the next generation graphical operating system. The result of the project was OS/2, but eventually Microsoft and IBM disagreed on many important issues and separated. OS/2 remained an IBM project. Microsoft started to work on Windows NT. The OS/2 filesystem HPFS contained several important new features. When Microsoft created their new operating system, they borrowed many of these concepts for NTFS. Probably as a result of this common ancestry, HPFS and NTFS share the same disk partition identification type code (07). Sharing an ID is unusual since there were dozens of available codes, and other major filesystems have their own code. FAT has more than nine (one each for FAT12, FAT16, FAT32, etc.). Algorithms which identify the filesystem in a partition type 07 must perform additional checks.

When it was first introduced, the acronym NTFS was understood to stand for New Technology File System. It was later abbreviated to NT File System and then to NTFS.

Versions

NTFS has five released versions:

• v1.0 with NT 3.1, released mid-1993
• v1.1 with NT 3.5, released fall 1994
• v1.2 written by NT 3.51 (mid-1995) and NT 4 (mid-1996) (occasionally referred to as "NTFS 4.0", because OS version is 4.0)
• v3.0 from Windows 2000 ("NTFS V5.0")
• v3.1 from Windows XP (autumn 2001; "NTFS V5.1"), Windows Server 2003 (spring 2003; occasionally "NTFS V5.2"), Windows Vista (mid-2005) (occasionally "NTFS V6.0") and Windows Server 2008

V1.0 and V1.1 (and newer) are incompatible: that is, volumes written by NT 3.5x cannot be read by NT 3.1 until an update on the NT 3.5x CD is applied to NT 3.1, which also adds FAT long file name support. V1.2 supports compressed files, named streams, ACL-based security, etc. V3.0 added disk quotas, encryption, sparse files, reparse points, update sequence number (USN) journaling, the $Extend folder and its files, and reorganized security descriptors so that multiple files which use the same security setting can share the same descriptor. V3.1 expanded the Master File Table (MFT) entries with redundant MFT record number (useful for recovering damaged MFT files).

Windows Vista introduced Transactional NTFS, NTFS symbolic links, partition shrinking and self-healing functionality though these features owe more to additional functionality of the operating system than the file system itself.

Features

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

Alternate data streams (ADS)

Alternate data streams allow more than one data stream to be associated with a filename, using the filename format "filename:streamname" (e.g., "text.txt:extrastream"). Alternate streams are not listed in Windows Explorer, and their size is not included in the file's size. Only the main stream of a file is preserved when it is copied to a network share or FAT-formatted USB drive, attached to an e-mail, or uploaded to a website. As a result, using alternate streams for critical data may cause problems.

Malware has used alternate data streams to hide its code; some malware scanners and other special tools now check for data in alternate streams.

Quotas

Disk quotas were introduced in NTFS v3. They allow the administrator of a computer that runs a version of Windows that supports NTFS to set a threshold of disk space that users may utilize. 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.

Sparse files

Sparse files are files which contain sparse data sets, data mostly filled with zeros. Database applications, for instance, sometimes use sparse files. Because of this, Microsoft has implemented support for efficient storage of sparse files by allowing an application to specify regions of empty (zero) data. An application that reads a sparse file reads it in the normal manner with the file system calculating what data should be returned based upon the file offset. As with compressed files, the actual size of sparse files are not taken into account when determining quota limits.

Reparse points

This feature was introduced in NTFS v3. These are used by associating a reparse tag in the user space attribute of a file or directory. When the object manager (see Windows NT line executive) parses a file system name lookup and encounters a reparse attribute, it knows to reparse the name lookup, passing the user controlled reparse data to every file system filter driver that is loaded into Windows 2000. Each filter driver examines the reparse data to see if it is associated with that reparse point, and if that filter driver determines a match then it intercepts the file system call and executes its special functionality. Reparse points are used to implement Volume Mount Points, Directory Junctions, Hierarchical Storage Management, Native Structured Storage, Single Instance Storage and Symbolic Links.

Volume mount points

Similar to Unix mount points, where the root of another file system is attached to a directory. In NTFS, this allows additional file systems to be mounted without requiring a separate drive letter (like C: or D:) for each.

Directory junctions

Similar to volume mount points, however directory junctions reference other directories in the file system instead of other volumes. For instance, the directory C:\exampledir with a directory junction attribute that contains a link to D:\linkeddir will automatically refer to the directory D:\linkeddir when it is accessed by a user-mode application. This function is conceptually similar to symbolic links to directories in Unix except that the target in NTFS must always be another directory (typical Unix file systems allow the target of a symbolic link to be any type of file).

Hard links

Originally included to support the POSIX subsystem in Windows NT, hard links are similar to directory junctions, but used for files instead of directories. Hard links can only be applied to files on the same volume since an additional filename record is added to the file's MFT record. Short (8.3) filenames are also implemented as additional filename records that don't have separate directory entries.

Hierarchical Storage Management (HSM)

Hierarchical Storage Management is a means of transferring files that are not used for some period of time to less expensive storage media. When the file is next accessed the reparse point on that file determines that it is needed and retrieves it from storage.

Native Structured Storage (NSS)

NSS was an ActiveX document storage technology that has since been discontinued by Microsoft. It allowed ActiveX Documents to be stored in the same multi-stream format that ActiveX uses internally. An NSS file system filter was loaded and used to process the multiple streams transparently to the application, and when the file was transferred to a non-NTFS formatted disk volume it would also transfer the multiple streams into a single stream.

Volume Shadow Copy

The Volume Shadow Copy Service (VSS) keeps historical versions of files and folders on NTFS volumes by copying old, newly-overwritten data to shadow copy (copy-on-write). The old file data is overlaid on the new when the user requests a revert to an earlier version. 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.

File compression

NTFS can compress files using a variant of the LZ77 algorithm (also used in the popular ZIP file format). 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.

Single-user systems with limited hard disk space will probably use NTFS compression successfully. The slowest link in a computer is not the CPU but the speed of the hard drive, so NTFS compression allows the limited, slow storage space to be better used, in terms of both space and (often) speed. NTFS compression can also serve as a replacement for sparse files when a program (e.g. a download manager) is not able to create files without content as sparse files.

Single Instance Storage (SIS)

When there are several directories that have different, but similar, files, some of these files may have identical content. Single instance storage allows identical files to be merged to one file and create references to that merged file. SIS consists of a file system filter that manages copies, modification and merges to files; and a user space service (or groveler) that searches for files that are identical and need merging. SIS was mainly designed for remote installation servers as these may have multiple installation images that contain many identical files; SIS allows these to be consolidated but, unlike for example hard links, each file remains distinct; changes to one copy of a file will leave others unaltered. This is similar to copy-on-write, which is a technique by which memory copying is not really done until one copy is modified.

Encrypting File System (EFS)

EFS 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 (FSRTL). EFS works by encrypting a file with a bulk 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 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 in to the EFS system, so that a recovery agent can still access the files if needed. NTFS-provided encryption and compression are mutually exclusive—NTFS can be used for one and a third party tool for the other.

Symbolic links

Symbolic links (or soft links) were introduced in Windows Vista. Symbolic links are resolved on the client side. So when a symbolic link is shared, the target is subject to the access restrictions on the client, and not the server.

See also: Computer shortcut

Transactional NTFS

As of Windows Vista, applications can use Transactional NTFS to group changes to files together into a transaction. The transaction will guarantee that all changes happen, or none of them do, and it will guarantee that applications outside the transaction will not see the changes until the precise instant they're committed.

USN Journal

The USN Journal is a system management feature that records changes to files and directories on the volume.

Interoperability

Details on the implementation's internals are closed, which makes it difficult for third-party vendors to provide tools to handle NTFS.

Linux

The ability to read and write to NTFS is provided by the NTFS-3G driver. It is included in most Linux distributions. Other outdated and mostly read-only solutions exist as well:

• Linux kernel 2.2: Kernel versions 2.2.0 and later include the ability to read NTFS partitions
• Linux kernel 2.6: Kernel versions 2.6.0 and later contain a driver written by Anton Altaparmakov (University of Cambridge) and Richard Russon. It supports file read, overwrite and resize.
• NTFSMount: A read/write userspace NTFS driver. It provides read-write access to NTFS, excluding writing compressed and encrypted files, changing file ownership, and access rights.
• NTFS for Linux: A commercial driver with full read/write support available from Paragon.
• Captive NTFS: A 'wrapping' driver which uses Windows' own driver, ntfs.sys.

Note that all three userspace drivers, namely NTFSMount, NTFS-3G and Captive NTFS, are built on the Filesystem in Userspace (FUSE), a Linux kernel module tasked with bridging userspace and kernel code to save and retrieve data. Almost all drivers listed above (except Paragon NTFS for Linux) are open source (GPL). Due to the complexity of internal NTFS structures, both the built-in 2.6.14 kernel driver and the FUSE drivers disallow changes to the volume that are considered unsafe, to avoid corruption.

Mac OS X

Mac OS X v10.3 and later include read-only support for NTFS-formatted partitions. A free third-party tool NTFS-3G also works on Mac OS X and allows reading and writing to NTFS partitions. A proprietary solution for Mac OS X with read/write access is "Paragon NTFS for Mac OS X".

Microsoft Windows

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" (a.k.a. Volume Shadow Copy) on an operating system that doesn't support it, will result in the contents of those previous versions being lost.

Others

eComStation, KolibriOS, and FreeBSD offer read-only NTFS support (there is a beta NTFS driver that allows write/delete for eComStation, but is generally considered unsafe). A free third-party tool for BeOS, which was based on NTFS-3G, allows full NTFS read and write. NTFS-3G also works on Mac OS X, FreeBSD, NetBSD, Solaris and Haiku besides Linux. A commercial read/write driver for DOS called "NTFS4DOS" also exists.

Compatibility with FAT

Microsoft currently provides a tool (convert.exe) to convert HPFS (only on Windows NT 3), FAT16 and, on Windows 2000 and higher, FAT32 to NTFS, but not the other way around. Various third-party tools are all capable of safely resizing NTFS partitions. Microsoft added the ability to shrink or expand a partition with Windows Vista, but this capability is limited because it will not relocate page file fragments or files that have been marked as unmovable, thus limiting the ability to shrink a partition. Rebooting without a page file or using a 3rd-party tool to defragment it may alleviate the situation if the pagefile is the unmovable file.

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. However, Windows NT and its descendants keep internal timestamps as UTC and make the appropriate conversions for display purposes. Therefore, NTFS timestamps are in UTC. This means that when files are copied or moved between NTFS and non-NTFS partitions, the OS needs to convert timestamps on the fly. But if some files are moved when daylight saving time (DST) is in effect, and other files are moved when standard time is in effect, there can be some ambiguities in the conversions. As a result, especially shortly after one of the days on which local zone time changes, users may observe that some files have timestamps that are incorrect by one hour. Due to the differences in implementation of DST between the northern and southern hemispheres, this can result in a potential timestamp error of up to 4 hours in any given 12 months.

Internals

In NTFS, all file data—file name, creation date, access permissions, and contents—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 interesting example is the addition of fields for indexing used by the Active Directory software.

NTFS allows any sequence of 16-bit values for name encoding (file names, stream names, index names, etc.). This means UTF-16 codepoints are supported, but the file system does not check whether a sequence is valid UTF-16 (it allows any sequence of short values, not restricted to those in the Unicode standard).

Internally, NTFS uses B+ trees to index file system data. Although complex to implement, this allows faster file look up times in most cases. 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.

The Master File Table (MFT) contains metadata about every file, directory, and metafile on an NTFS volume. It includes filenames, locations, size, and permissions. Its 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.

Metafiles

NTFS contains several files which define and organize the file system. In all respects, most of these files are structured like any other user file ($Volume being the most peculiar), but are not of direct interest to file system clients. These metafiles define files, back up critical file system data, buffer file system changes, manage free space allocation, satisfy BIOS expectations, track bad allocation units, and store security and disk space usage information. All content is in an unnamed data stream, unless otherwise indicated.

Segment Number	File Name	Purpose
0	$MFT	Describes all files on the volume, including file names, timestamps, stream names, and lists of cluster numbers where data streams reside, indexes, security identifiers, and file attributes like "read only", "compressed", "encrypted", etc.
1	$MFTMirr	Duplicate of the first vital entries of $MFT, usually 4 entries (4 KiB).
2	$LogFile	Contains transaction log of file system metadata changes.
3	$Volume	Contains information about the volume, namely the volume object identifier, volume label, file system version, and volume flags (mounted, chkdsk requested, requested $LogFile resize, mounted on NT 4, volume serial number updating, structure upgrade request). This data is not stored in a data stream, but in special MFT attributes: If present, a volume object ID is stored in an $OBJECT_ID record; the volume label is stored in a $VOLUME_NAME record, and the remaining volume data is in a $VOLUME_INFORMATION record. Note: volume serial number is stored in file $Boot (below).
4	$AttrDef	A table of MFT attributes which associates numeric identifiers with names.
5	.	Root directory. Directory data is stored in $INDEX_ROOT and $INDEX_ALLOCATION attributes both named $I30.
6	$Bitmap	An array of bit entries: each bit indicates whether its corresponding cluster is used (allocated) or free (available for allocation).
7	$Boot	Volume boot record. This file is always located at the first clusters on the volume. It contains bootstrap code (see NTLDR/BOOTMGR) and a BIOS parameter block including a volume serial number and cluster numbers of $MFT and $MFTMirr. $Boot is usually 8192 bytes long.
8	$BadClus	A file which contains all the clusters marked as having bad sectors. This file simplifies cluster management by the chkdsk utility, both as a place to put newly discovered bad sectors, and for identifying unreferenced clusters. This file contains two data streams, even on volumes with no bad sectors: an unnamed stream contains bad sectors—it is zero length for perfect volumes; the second stream is named $Bad and contains all clusters on the volume not in the first stream.
9	$Secure	Access control list database which reduces overhead having many identical ACLs stored with each file, by uniquely storing these ACLs in this database only (contains two indices $SII: perhaps Security ID Index and $SDH: Security Descriptor Hash which index the stream named $SDS containing actual ACL table).
10	$UpCase	A table of unicode uppercase characters for ensuring case insensitivity in Win32 and DOS namespaces.
11	$Extend	A filesystem directory containing various optional extensions, such as $Quota, $ObjId, $Reparse or $UsnJrnl.
12 ... 23	Reserved for $MFT extension entries.
usually 24	$Extend\$Quota	Holds disk quota information. Contains two index roots, named $O and $Q.
usually 25	$Extend\$ObjId	Holds distributed link tracking information. Contains an index root and allocation named $O.
usually 26	$Extend\$Reparse	Holds reparse point data (such as symbolic links). Contains an index root and allocation named $R.
27 ...	file.ext	Beginning of regular file entries.

These metafiles are treated specially by Windows and are difficult to directly view: special purpose-built tools are needed.

Resident vs. non-resident files

To optimize storage for the common case of small data files, NTFS prefers to place file data within the master file table if it fits instead of using MFT space to list clusters containing the data. The former is called "resident data" by computer forensics workers. The amount of data which 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. Encrypted-by-NTFS, sparse, or compressed files cannot be resident.

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, an 80 GB (74.5 GiB) partition NTFS formats with 19,543,064 clusters of 4 KiB. Subtracting system files (64 MiB 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.

Limitations

The following are a few limitations of NTFS:

Reserved File Names

Though the file system supports paths up to about 32767 Unicode characters with each path component (directory or filename) up to 255 characters long, certain names are unusable, since NTFS stores its metadata in regular (albeit hidden and for the most part inaccessible) files; accordingly, user files cannot use these names. These files are all in the root directory of a volume (and are reserved only for that directory). The names are: $MFT, $MFTMirr, $LogFile, $Volume, $AttrDef, . (dot), $Bitmap, $Boot, $BadClus, $Secure, $Upcase, and $Extend; . (dot) and $Extend are both directories; the others are files.

Maximum Volume Size

In theory, the maximum NTFS volume size is 2⁶⁴-1 clusters. However, the maximum NTFS volume size as implemented in Windows XP Professional is 2³²-1 clusters. For example, using 64 KiB clusters, the maximum NTFS volume size is 256 TiB minus 64 KiB. Using the default cluster size of 4 KiB, the maximum NTFS volume size is 16 TiB minus 4 KiB. (Both of these are vastly higher than the 137 GiB limit lifted in Windows XP SP1.) Because partition tables on master boot record (MBR) disks only support partition sizes up to 2 TiB, dynamic or GPT volumes must be used to create bootable NTFS volumes over 2 TiB.

Maximum File Size

Theoretical: 16 EiB minus 1 KiB ($2^{64}-2^{10}$ or 18,446,744,073,709,550,592 bytes). Implementation: 16 TiB minus 64 KiB ($2^{44}-2^{16}$ or 17,592,185,978,880 bytes)

Alternate Data Streams

Windows system calls may—or may not—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 offending streams.

Maximum path length

An absolute path may be up to 32767 characters long; a relative path is limited to 255 characters.

Date range

NTFS uses the same time reckoning as Windows NT: 64-bit timestamps with a range from January 1, 1601 to May 28, 60056 at a resolution of ten million ticks per second.

Developers

NTFS developers include:

• Tom Miller
• Gary Kimura
• Brian Andrew
• David Goebel

See also

• Comparison of file systems
• Files-11 — ODS-2 is structurally very similar to NTFS (compare INDEXF.SYS and $Mft, and BITMAP.SYS and $Bitmap, for examples)
• HPFS, file system created for the OS/2 operating system
• ntfsresize
• Samba (software)

Further Reading

• Bolosky, William J.; Corbin, Scott; Goebel, David; & Douceur, John R. (date). "Single Instance Storage in Windows 2000" (PDF). Microsoft Research & Balder Technology Group, Inc. {{cite journal}}: Check date values in: |date= (help); Cite journal requires |journal= (help)CS1 maint: multiple names: authors list (link)
• Custer, Helen (1994). Inside the Windows NT File System. Microsoft Press. ISBN 978-1-55615-660-1.
• Nagar, Rajeev (1997). Windows NT File System Internals: A Developer's Guide. O'Reilly. ISBN 978-1-56592-249-5.

External links

• Documentation:
  • Low-level description of NTFS disk structures from the Linux-NTFS project
  • NTFS.com – documentation and resources for NTFS
  • Microsoft NTFS Technical Reference
• Implementations:
  • NTFS-3G – NTFS-3G an open source read/write NTFS driver for Linux, FreeBSD, Mac OS X, NetBSD, Solaris and Haiku.
  • Linux-NTFS – an open source project to add NTFS support to the Linux kernel (write support is limited, but can be used for simple tasks), and write POSIX-compatible utilities for accessing and manipulating NTFS (ntfsprogs; includes ntfsls, ntfsresize, ntfsclone, etc). Linux NTFS FAQ and howto
  • Captive NTFS – Captive NTFS a shim which used the Windows NTFS driver to access NTFS file systems under Linux