NTFS

Neue Technologie Dateisystem ⓘ

Entwickler(n)	Microsoft
Vollständiger Name	NT-Dateisystem
Eingeführt	Juli 1993; vor 29 Jahren mit Windows NT 3.1
Kennung der Partition	0x07 (MBR) EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (GPT)
Strukturen
Inhalt des Verzeichnisses	B-Baum-Variante
Dateizuordnung	Bitmap
Schlechte Blöcke	$BadClus (MFT-Satz)
Begrenzungen
Max. Volume-Größe	264 Cluster - 1 Cluster (Format); 256 TiB - 64 KB (Windows 10 Version 1703, Windows Server 2016 oder frühere Implementierungen) 8 PB - 2 MB (Windows 10 Version 1709, Windows Server 2019 oder spätere Implementierung)
Max. Dateigröße	16 EiB - 1 KB (Format); 16 TB - 64 KB (Windows 7, Windows Server 2008 R2 oder frühere Implementierungen) 256 TB - 64 KB (Windows 8, Windows Server 2012 oder spätere Implementierungen) 8 PB - 2 MiB (Windows 10 Version 1709, Windows Server 2019 oder spätere Implementierungen)
Max. Anzahl von Dateien	4,294,967,295 (232-1)
Max. Länge des Dateinamens	255 UTF-16-Code-Einheiten
Erlaubte Zeichen in Dateinamen	Im Win32-Namensraum: jede UTF-16-Codeeinheit (Groß- und Kleinschreibung wird nicht berücksichtigt) außer /\:*"?<>| sowie NUL Im POSIX-Namensraum: jede UTF-16-Codeeinheit (Groß-/Kleinschreibung wird beachtet) außer / sowie NUL Nachfolgende Leerzeichen sind nicht erlaubt und werden entfernt.
Merkmale
Aufgezeichnete Daten	Erstellung, Änderung, POSIX-Änderung, Zugriff
Datumsbereich	1. Januar 1601 - 28. Mai 60056 (Dateizeiten sind 63-Bit-Zahlen, die 100-Nanosekunden-Intervalle (zehn Millionen pro Sekunde) seit 1601 zählen, was 29.227 Jahren entspricht)
Auflösung des Datums	100 ns
Gabeln	Ja (siehe § Alternativer Datenstrom (ADS) unten)
Attribute	Schreibgeschützt, versteckt, System, Archiv, nicht inhaltsindiziert, offline, temporär, komprimiert
Dateisystem-Berechtigungen	ACLs
Transparente Komprimierung	Pro Datei, LZ77 (ab Windows NT 3.51)
Transparente Verschlüsselung	Pro Datei, DESX (ab Windows 2000), Triple DES (ab Windows XP), AES (ab Windows XP Service Pack 1, ab Windows Server 2003)
Datendeduplizierung	Ja (Windows Server 2012)
Andere
Unterstützte Betriebssysteme	Windows NT 3.1 und höher Mac OS X 10.3 und höher (schreibgeschützt) Linux-Kernel Version 2.6 und höher Linux-Kernel-Versionen 2.2-2.4 (schreibgeschützt) FreeBSD NetBSD OpenBSD (nur Lesezugriff) Chrome OS Solaris ReactOS (nur Lesezugriff)

New Technology File System (NTFS) ist ein von Microsoft entwickeltes proprietäres Journaling-Dateisystem. Seit Windows NT 3.1 ist es das Standard-Dateisystem der Windows NT-Familie. Es hat die File Allocation Table (FAT) als bevorzugtes Dateisystem unter Windows abgelöst und wird auch von Linux und BSD unterstützt. NTFS-Lese- und Schreibunterstützung wird durch eine freie und quelloffene Kernel-Implementierung namens NTFS3 in Linux und den NTFS-3G-Treiber in BSD bereitgestellt. Mit dem Befehl convert kann Windows FAT32/16/12 in NTFS konvertieren, ohne dass alle Dateien neu geschrieben werden müssen. NTFS verwendet mehrere Dateien, die in der Regel vor dem Benutzer verborgen sind, um Metadaten über andere auf dem Laufwerk gespeicherte Dateien zu speichern, was die Geschwindigkeit und Leistung beim Lesen von Daten verbessern kann. Im Gegensatz zu FAT und High Performance File System (HPFS) unterstützt NTFS Zugriffskontrolllisten (ACLs), Dateisystemverschlüsselung, transparente Komprimierung, spärliche Dateien und Dateisystem-Journaling. NTFS unterstützt auch Schattenkopien, um Backups eines laufenden Systems zu ermöglichen, aber die Funktionalität der Schattenkopien variiert zwischen verschiedenen Windows-Versionen. ⓘ

Geschichte

Mitte der 1980er Jahre schlossen sich Microsoft und IBM zu einem gemeinsamen Projekt zusammen, um die nächste Generation von grafischen Betriebssystemen zu entwickeln; das Ergebnis waren OS/2 und HPFS. Da Microsoft und IBM in vielen wichtigen Fragen nicht einer Meinung waren, trennten sie sich schließlich; OS/2 blieb ein IBM-Projekt und Microsoft arbeitete an der Entwicklung von Windows NT und NTFS. ⓘ

Das HPFS-Dateisystem für OS/2 enthielt mehrere wichtige neue Funktionen. Als Microsoft sein neues Betriebssystem entwickelte, "borgte" es sich viele dieser Konzepte für NTFS. Die ursprünglichen NTFS-Entwickler waren Tom Miller, Gary Kimura, Brian Andrew und David Goebel. ⓘ

Wahrscheinlich als Ergebnis dieser gemeinsamen Vorfahren verwenden HPFS und NTFS denselben Partitionsidentifikationstyp (07). Die Verwendung der gleichen Partitions-ID-Datensatznummer ist höchst ungewöhnlich, da es Dutzende unbenutzter Codenummern gab und andere wichtige Dateisysteme ihre eigenen Codes haben. FAT hat zum Beispiel mehr als neun (je eine für FAT12, FAT16, FAT32 usw.). Algorithmen, die das Dateisystem in einem Partitionstyp 07 identifizieren, müssen zusätzliche Prüfungen durchführen, um zwischen HPFS und NTFS zu unterscheiden. ⓘ

Versionen

Microsoft hat fünf Versionen von NTFS herausgegeben:

NTFS Versionsnummer	Erstes Betriebssystem	Datum der Veröffentlichung	Neue Funktionen	Bemerkungen ⓘ
1.0	Windows NT 3.1	1993	Erste Version	NTFS 1.0 ist inkompatibel mit 1.1 und neuer: Datenträger, die von Windows NT 3.5x geschrieben wurden, können von Windows NT 3.1 nicht gelesen werden, bis ein Update (verfügbar auf dem NT 3.5x-Installationsmedium) installiert wird.
1.1	Windows NT 3.51	1995	Komprimierte Dateien, benannte Datenströme und Zugriffskontrolllisten
1.2	Windows NT 4.0	1996	Sicherheitsdeskriptoren	Nach der Veröffentlichung des Betriebssystems gemeinhin als NTFS 4.0 bezeichnet
3.0	Windows 2000	2000	Festplattenkontingente, Verschlüsselung auf Dateiebene in Form eines verschlüsselnden Dateisystems, Sparse-Dateien, Reparse-Points, USN-Journaling (Update Sequence Number), verteilte Link-Verfolgung, der Ordner $Extend und seine Dateien	Die Kompatibilität wurde auch für Windows NT 4.0 mit dem Service Pack 4 Update hergestellt. Nach der Veröffentlichung des Betriebssystems wird es allgemein als NTFS 5.0 bezeichnet.
3.1	Windows XP	Oktober 2001	Erweiterung der Master File Table (MFT)-Einträge mit redundanter MFT-Datensatznummer (nützlich für die Wiederherstellung beschädigter MFT-Dateien)	Nach der Freigabe des Betriebssystems üblicherweise NTFS 5.1 genannt.

Die NTFS.sys Versionsnummer (z. B. v5.0 in Windows 2000) basiert auf der Version des Betriebssystems; sie sollte nicht mit der NTFS-Versionsnummer (v3.1 seit Windows XP) verwechselt werden. ⓘ

Obwohl nachfolgende Versionen von Windows neue dateisystembezogene Funktionen hinzufügten, haben sie NTFS selbst nicht verändert. So wurden beispielsweise mit Windows Vista symbolische NTFS-Links, transaktionales NTFS, Partitionsverkleinerung und Selbstheilung eingeführt. Symbolische NTFS-Links sind eine neue Funktion des Dateisystems; alle anderen sind neue Betriebssystemfunktionen, die bereits vorhandene NTFS-Funktionen nutzen. ⓘ

Skalierbarkeit

NTFS ist für 4-KB-Cluster optimiert, unterstützt aber eine maximale Clustergröße von 2 MB. (Frühere Implementierungen unterstützen bis zu 64 KB.) Die maximale NTFS-Datenträgergröße, die von der Spezifikation unterstützt werden kann, beträgt 2⁶⁴ - 1 Cluster, aber nicht alle Implementierungen erreichen dieses theoretische Maximum, wie unten beschrieben. ⓘ

Die maximale NTFS-Volumegröße, die in Windows XP Professional implementiert ist, beträgt 2³² - 1 Cluster, was zum Teil auf die Einschränkungen der Partitionstabelle zurückzuführen ist. Bei Verwendung von 64 KB-Clustern beträgt die maximale Größe eines Windows XP-NTFS-Volumes beispielsweise 256 TB minus 64 KB. Bei Verwendung der Standardclustergröße von 4 KB beträgt die maximale NTFS-Volumengröße 16 TB minus 4 KB. Beide Werte liegen weit über dem Limit von 128 GB in Windows XP SP1. Da Partitionstabellen auf Master-Boot-Record-Platten (MBR) nur Partitionsgrößen bis zu 2 TB unterstützen, müssen mehrere GUID-Partitionstabellen- (GPT- oder "dynamische") Volumes kombiniert werden, um ein einzelnes NTFS-Volume mit mehr als 2 TB zu erstellen. Das Booten von einem GPT-Volume in einer von Microsoft unterstützten Windows-Umgebung erfordert ein System mit Unified Extensible Firmware Interface (UEFI) und 64-Bit-Unterstützung. ⓘ

Die theoretische Höchstgrenze für die Größe einzelner Dateien beträgt bei NTFS 16 EB (16 × 1024⁶ oder 2⁶⁴ Byte) minus 1 KB, was insgesamt 18.446.744.073.709.550.592 Byte ergibt. Bei Windows 10 Version 1709 und Windows Server 2019 beträgt die maximale implementierte Dateigröße 8 PB minus 2 MB oder 9.007.199.252.643.840 Bytes. ⓘ

Interoperabilität

Windows

Während die verschiedenen NTFS-Versionen größtenteils vollständig vorwärts- und rückwärtskompatibel sind, gibt es technische Überlegungen für das Mounten neuerer NTFS-Volumes in älteren Versionen von Microsoft Windows. Dies betrifft den Dual-Boot-Betrieb und externe tragbare Festplatten. Der Versuch, eine NTFS-Partition mit "Vorgängerversionen" (Volume Shadow Copy) unter einem Betriebssystem zu verwenden, das dies nicht unterstützt, führt zum Verlust des Inhalts dieser Vorgängerversionen. Ein Windows-Befehlszeilenprogramm namens convert.exe kann unterstützte Dateisysteme nach NTFS konvertieren, einschließlich HPFS (nur unter Windows NT 3.1, 3.5 und 3.51), FAT16 und FAT32 (unter Windows 2000 und später). ⓘ

FreeBSD

FreeBSD 3.2, das im Mai 1999 veröffentlicht wurde, enthielt von Semen Ustimenko geschriebene Nur-Lese-Unterstützung für NTFS. Diese Implementierung wurde von Christos Zoulas und Jaromir Dolecek auf NetBSD portiert und mit NetBSD 1.5 im Dezember 2000 veröffentlicht. Die FreeBSD-Implementierung von NTFS wurde ebenfalls von Julien Bordet nach OpenBSD portiert und bietet seit der am 1. Mai 2011 veröffentlichten Version 4.9 auf den Plattformen i386 und amd64 standardmäßig native Nur-Lese-NTFS-Unterstützung. ⓘ

Linux

Die Linux-Kernel-Versionen 2.1.74 und später enthalten einen von Martin von Löwis geschriebenen Treiber, der NTFS-Partitionen lesen kann; die Kernel-Versionen 2.5.11 und später enthalten einen neuen, von Anton Altaparmakov (Universität Cambridge) und Richard Russon geschriebenen Treiber, der das Lesen von Dateien unterstützt. Die Fähigkeit, in Dateien zu schreiben, wurde mit der Kernel-Version 2.6.15 im Jahr 2006 eingeführt, die es Benutzern ermöglicht, in bestehende Dateien zu schreiben, aber keine neuen Dateien zu erstellen. Der NTFS-Treiber von Paragon (siehe unten) wurde in die Kernel-Version 5.15 integriert und unterstützt das Lesen/Schreiben von normalen, komprimierten und spärlichen Dateien sowie die Journal-Wiedergabe. ⓘ

NTFS-3G ist eine freie, unter der GPL lizenzierte FUSE-Implementierung von NTFS, die ursprünglich als Linux-Kernel-Treiber von Szabolcs Szakacsits entwickelt wurde. Es wurde als FUSE-Programm umgeschrieben, um auf anderen Systemen zu funktionieren, die von FUSE unterstützt werden, wie macOS, FreeBSD, NetBSD, OpenBSD, Solaris, QNX und Haiku, und ermöglicht das Lesen und Schreiben auf NTFS-Partitionen. Eine leistungsgesteigerte kommerzielle Version von NTFS-3G, genannt "Tuxera NTFS for Mac", ist ebenfalls von den NTFS-3G-Entwicklern erhältlich. ⓘ

Captive NTFS, ein "Wrapping"-Treiber, der den Windows-eigenen Treiber ntfs.sys verwendet, existiert für Linux. Er wurde als Filesystem in Userspace (FUSE)-Programm entwickelt und unter der GPL veröffentlicht, aber die Arbeit an Captive NTFS wurde 2006 eingestellt. ⓘ

Linux-Kernel-Versionen ab 5.15 enthalten NTFS3, einen voll funktionsfähigen NTFS-Lese-/Schreib-Treiber, der mit NTFS-Versionen bis 3.1 funktioniert und hauptsächlich von der Paragon Software Group gepflegt wird; den Quellcode finden Sie hier. ⓘ

Mac OS

Mac OS X 10.3 enthielt Ustimenkos Nur-Lese-Implementierung von NTFS aus FreeBSD. Im Jahr 2006 beauftragte Apple Anton Altaparmakov, eine neue NTFS-Implementierung für Mac OS X 10.6 zu schreiben. Native NTFS-Schreibunterstützung ist in 10.6 und neuer enthalten, ist aber nicht standardmäßig aktiviert, obwohl es Workarounds gibt, um die Funktionalität zu aktivieren. Benutzerberichte deuten jedoch darauf hin, dass die Funktionalität instabil ist und dazu neigt, Kernel-Panics zu verursachen. ⓘ

Die Paragon Software Group vertreibt einen Schreib-Lese-Treiber namens NTFS für Mac OS X, der auch in einigen Modellen von Seagate-Festplatten enthalten ist. ⓘ

OS/2

Das NetDrive-Paket für OS/2 (und Derivate wie eComStation und ArcaOS) unterstützt ein Plugin, das Lese- und Schreibzugriff auf NTFS-Volumes ermöglicht. ⓘ

DOS

Es gibt einen kostenlosen Lese-/Schreibtreiber-Treiber für MS-DOS von Avira namens "NTFS4DOS". ⓘ

Ahead Software entwickelte zwischen 2002 und 2004 einen "NTFSREAD"-Treiber (Version 1.200) für DR-DOS 7.0x. Er war Teil der Nero Burning ROM-Software. ⓘ

Für DOS-basierte Betriebssysteme, zu denen auch die Betriebssysteme Windows-9x-Reihe zählen, existieren Treiber wie NTFS4DOS, die einen vollständigen Zugriff auf NTFS-Laufwerke ermöglichen. ⓘ

Sicherheit

NTFS verwendet Zugriffskontrolllisten und Verschlüsselung auf Benutzerebene, um Benutzerdaten zu schützen. ⓘ

Zugriffskontrolllisten (ACLs)

NTFS-Dateisystemberechtigungen auf einem modernen Windows-System ⓘ

In NTFS wird jeder Datei oder jedem Ordner ein Sicherheitsdeskriptor zugewiesen, der den Eigentümer definiert und zwei Zugriffskontrolllisten (ACLs) enthält. Die erste ACL, die so genannte Discretionary Access Control List (DACL), legt genau fest, welche Art von Interaktionen (z. B. Lesen, Schreiben, Ausführen oder Löschen) von welchen Benutzern oder Benutzergruppen erlaubt oder verboten sind. Zum Beispiel können Dateien im Verzeichnis C:\Programmdateien von allen Benutzern gelesen und ausgeführt werden, aber nur von einem Benutzer mit administrativen Rechten geändert werden. Windows Vista fügt den DACLs obligatorische Informationen zur Zugriffskontrolle hinzu. DACLs sind das Hauptaugenmerk der Benutzerkontensteuerung in Windows Vista und höher. ⓘ

Die zweite ACL, die so genannte Systemzugriffskontrollliste (SACL), legt fest, welche Interaktionen mit der Datei oder dem Ordner überwacht werden sollen und ob sie protokolliert werden sollen, wenn die Aktivität erfolgreich, fehlgeschlagen oder beides ist. So kann beispielsweise die Überwachung sensibler Dateien eines Unternehmens aktiviert werden, so dass die Verantwortlichen erfahren, wenn jemand versucht, sie zu löschen oder eine Kopie davon zu erstellen, und ob er oder sie erfolgreich ist. ⓘ

Verschlüsselung

Encrypting File System (EFS) bietet eine für den Benutzer transparente Verschlüsselung aller Dateien und Ordner auf einem NTFS-Volume. EFS funktioniert in Verbindung mit dem EFS-Dienst, der CryptoAPI von Microsoft und der EFS File System Run-Time Library (FSRTL). EFS funktioniert durch die Verschlüsselung einer Datei mit einem symmetrischen Massenschlüssel (auch bekannt als File Encryption Key oder FEK), der verwendet wird, weil es relativ wenig Zeit in Anspruch nimmt, große Datenmengen zu ver- und entschlüsseln, als wenn eine asymmetrische Chiffre verwendet wird. Der symmetrische Schlüssel, der zur Verschlüsselung der Datei verwendet wird, wird dann mit einem öffentlichen Schlüssel verschlüsselt, der dem Benutzer zugeordnet ist, der die Datei verschlüsselt hat, und diese verschlüsselten Daten werden in einem alternativen Datenstrom der verschlüsselten Datei gespeichert. Zur Entschlüsselung der Datei verwendet das Dateisystem den privaten Schlüssel des Benutzers, um den symmetrischen Schlüssel zu entschlüsseln, der im Datenstrom gespeichert ist. Anschließend verwendet es den symmetrischen Schlüssel, um die Datei zu entschlüsseln. Da dieser Vorgang auf Dateisystemebene stattfindet, ist er für den Benutzer transparent. Für den Fall, dass ein Benutzer den Zugriff auf seinen Schlüssel verliert, wurde außerdem Unterstützung für zusätzliche Entschlüsselungsschlüssel in das EFS-System eingebaut, so dass ein Wiederherstellungsagent bei Bedarf weiterhin auf die Dateien zugreifen kann. Die von NTFS bereitgestellte Verschlüsselung und die von NTFS bereitgestellte Komprimierung schließen sich gegenseitig aus; allerdings kann NTFS für das eine und ein Drittanbieterwerkzeug für das andere verwendet werden. ⓘ

Die Unterstützung von EFS ist in den Basic-, Home- und MediaCenter-Versionen von Windows nicht verfügbar und muss nach der Installation der Professional-, Ultimate- und Server-Versionen von Windows oder durch die Verwendung von Unternehmensbereitstellungstools innerhalb von Windows-Domänen aktiviert werden. ⓘ

Merkmale

Journaling

NTFS ist ein Journaling-Dateisystem und verwendet das NTFS-Protokoll ($LogFile), um Metadatenänderungen auf dem Volume aufzuzeichnen. Dies ist eine Funktion, die FAT nicht bietet und die für NTFS von entscheidender Bedeutung ist, um sicherzustellen, dass seine komplexen internen Datenstrukturen im Falle von Systemabstürzen oder Datenverschiebungen durch die Defragmentierungs-API konsistent bleiben, und um ein einfaches Rollback von unbestätigten Änderungen an diesen kritischen Datenstrukturen zu ermöglichen, wenn das Volume neu gemountet wird. Davon betroffen sind insbesondere die Datenträgerzuordnungs-Bitmap, Änderungen an MFT-Datensätzen, wie z. B. das Verschieben einiger in MFT-Datensätzen und Attributlisten gespeicherter Attribute variabler Länge, sowie Indizes für Verzeichnisse und Sicherheitsdeskriptoren. ⓘ

Das ($LogFile)-Format hat sich über mehrere Versionen entwickelt:

Windows-Version	Version des $LogFile-Formats ⓘ
Windows NT 4.0	1.1
Windows 2000
Windows XP
Windows Vista
Windows 7
Windows 8
Windows 8.1	2.0
Windows 10

Die Inkompatibilität der von Windows 8.1 und Windows 10 implementierten $LogFile-Versionen verhindert, dass Windows 8 (und frühere Versionen von Windows) die Version 2.0 der $LogFile erkennt. Die Abwärtskompatibilität wird dadurch gewährleistet, dass die $LogFile auf Version 1.1 herabgestuft wird, wenn ein NTFS-Volume sauber abgehängt wird. Sie wird wieder auf Version 2.0 hochgestuft, wenn sie auf einer kompatiblen Version von Windows gemountet wird. Beim Ruhezustand auf Festplatte im Abmeldezustand (auch bekannt als Hybrid-Boot oder Fast-Boot, was standardmäßig aktiviert ist) werden gemountete Dateisysteme jedoch nicht demontiert, und daher werden die $LogFiles aller aktiven Dateisysteme nicht auf Version 1.1 herabgestuft. Die Unfähigkeit, Version 2.0 der $LogFile von Windows-Versionen älter als 8.1 zu verarbeiten, führt zu einem unnötigen Aufruf des Festplattenreparaturprogramms CHKDSK. Dies ist besonders problematisch in einem Multi-Boot-Szenario mit Vor- und Nach-8.1-Versionen von Windows oder beim häufigen Verschieben eines Speichergeräts zwischen älteren und neueren Versionen. Es gibt eine Windows-Registrierungseinstellung, die die automatische Aktualisierung der $LogFile auf die neuere Version verhindert. Das Problem kann auch durch die Deaktivierung von Hybrid Boot behoben werden. ⓘ

Das USN-Journal (Update Sequence Number Journal) ist eine Systemverwaltungsfunktion, die (in $Extend\$UsnJrnl) Änderungen an Dateien, Streams und Verzeichnissen auf dem Volume sowie deren verschiedene Attribute und Sicherheitseinstellungen aufzeichnet. Das Journal wird für Anwendungen zur Verfügung gestellt, um Änderungen am Volume zu verfolgen. Dieses Journal kann auf Nicht-System-Volumes aktiviert oder deaktiviert werden. ⓘ

Harte Links

Die Hardlink-Funktion ermöglicht es, dass verschiedene Dateinamen direkt auf denselben Dateiinhalt verweisen. Harte Links können nur auf Dateien desselben Volumes verweisen, da jedes Volume seine eigene MFT hat. Harte Links wurden ursprünglich eingeführt, um das POSIX-Subsystem in Windows NT zu unterstützen. ⓘ

Obwohl Hard Links denselben MFT-Datensatz (Inode) verwenden, der Dateimetadaten wie Dateigröße, Änderungsdatum und Attribute aufzeichnet, speichert NTFS diese Daten zur Leistungssteigerung auch im Verzeichniseintrag. Das bedeutet, dass Sie bei der Auflistung des Inhalts eines Verzeichnisses mit den APIs der FindFirstFile/FindNextFile-Familie (entspricht den POSIX-APIs opendir/readdir) neben dem Namen und der Inode auch diese zwischengespeicherten Informationen erhalten. Es kann jedoch sein, dass diese Informationen nicht mehr aktuell sind, da sie nur dann aktualisiert werden, wenn eine Datei geschlossen wird, und dann auch nur für das Verzeichnis, aus dem die Datei geöffnet wurde. Das heißt, wenn eine Datei über Hardlinks mehrere Namen hat, werden bei der Aktualisierung einer Datei über einen Namen die mit dem anderen Namen verbundenen Cache-Daten nicht aktualisiert. Mit GetFileInformationByHandle (der echten Entsprechung der POSIX-Stat-Funktion) können Sie immer aktuelle Daten abrufen. Dies kann mit einem Handle geschehen, das keinen Zugriff auf die Datei selbst hat (Übergabe von Null an CreateFile für dwDesiredAccess), und das Schließen dieses Handles hat den beiläufigen Effekt, dass die zwischengespeicherten Informationen aktualisiert werden. ⓘ

Windows verwendet Hardlinks, um kurze (8.3) Dateinamen in NTFS zu unterstützen. Die Unterstützung durch das Betriebssystem ist erforderlich, da es ältere Anwendungen gibt, die nur mit 8.3-Dateinamen arbeiten können, aber die Unterstützung kann deaktiviert werden. In diesem Fall wird ein zusätzlicher Datensatz und Verzeichniseintrag hinzugefügt, aber sowohl der 8.3-Dateiname als auch der lange Dateiname werden zusammen verknüpft und aktualisiert, im Gegensatz zu einem normalen Hardlink. ⓘ

Das NTFS-Dateisystem hat eine Obergrenze von 1024 harten Links für eine Datei. ⓘ

Alternativer Datenstrom (ADS)

Alternative Datenströme erlauben es, mehr als einen Datenstrom mit einem Dateinamen (einem Fork) zu verknüpfen, wobei das Format "Dateiname:Streamname" verwendet wird (z. B. "text.txt:extrastream"). ⓘ

NTFS-Streams wurden in Windows NT 3.1 eingeführt, um Services for Macintosh (SFM) die Speicherung von Ressourcenzweigen zu ermöglichen. Obwohl aktuelle Versionen von Windows Server SFM nicht mehr enthalten, verwenden Produkte von Drittanbietern (wie ExtremeZ-IP von GroupLogic) diese Funktion des Dateisystems weiterhin. Sehr kleine ADS (mit der Bezeichnung "Zone.Identifier") werden vom Internet Explorer und in letzter Zeit auch von anderen Browsern hinzugefügt, um Dateien, die von externen Websites heruntergeladen wurden, als möglicherweise unsicher für die Ausführung zu kennzeichnen; die lokale Shell würde dann eine Bestätigung des Benutzers erfordern, bevor sie geöffnet werden. Wenn der Benutzer angibt, dass er diesen Bestätigungsdialog nicht mehr wünscht, wird diese ADS gelöscht. ⓘ

Alternative Streams werden im Windows Explorer nicht aufgelistet, und ihre Größe wird nicht in die Dateigröße einbezogen. Wenn die Datei in ein anderes Dateisystem ohne ADS-Unterstützung kopiert oder verschoben wird, wird der Benutzer gewarnt, dass die alternativen Datenströme nicht erhalten werden können. Wenn die Datei an eine E-Mail angehängt oder auf eine Website hochgeladen wird, erfolgt in der Regel keine solche Warnung. Daher kann die Verwendung alternativer Datenströme für kritische Daten zu Problemen führen. Microsoft bietet ein Tool namens Streams zum Anzeigen von Streams auf einem ausgewählten Volume. Ab Windows PowerShell 3.0 ist es möglich, ADS nativ mit sechs Cmdlets zu verwalten: Add-Content, Clear-Content, Get-Content, Get-Item, Remove-Item, Set-Content. ⓘ

Malware hat alternative Datenströme verwendet, um Code zu verstecken. Daher suchen Malware-Scanner und andere spezielle Tools jetzt nach alternativen Datenströmen. ⓘ

Dateikomprimierung

Die Komprimierung wird für jeden Ordner oder jede Datei aktiviert, indem das Attribut "komprimiert" gesetzt wird. Wenn die Komprimierung für einen Ordner aktiviert ist, werden alle Dateien, die in diesen Ordner verschoben oder gespeichert werden, automatisch mit dem LZNT1-Algorithmus (einer Variante von LZ77) komprimiert. Der Komprimierungsalgorithmus ist so konzipiert, dass er Clustergrößen von bis zu 4 KB unterstützt; wenn die Clustergröße auf einem NTFS-Volume größer als 4 KB ist, ist die NTFS-Komprimierung nicht verfügbar. Daten werden in 16-Cluster-Blöcken (bis zu 64 KB groß) komprimiert; wenn die Komprimierung 64 KB Daten auf 60 KB oder weniger reduziert, behandelt NTFS die nicht benötigten 4-KB-Seiten wie leere Sparse-File-Cluster - sie werden nicht geschrieben. Dies ermöglicht angemessene Zufallszugriffszeiten, da das Betriebssystem lediglich der Kette der Fragmente folgen muss. ⓘ

Die Komprimierung funktioniert am besten bei Dateien mit sich wiederholendem Inhalt, die selten geschrieben werden, auf die normalerweise sequentiell zugegriffen wird und die selbst nicht komprimiert sind. Einzelplatzsysteme mit begrenztem Festplattenspeicherplatz können von der NTFS-Komprimierung für kleine Dateien profitieren, die je nach Komprimierbarkeit zwischen 4 KB und 64 KB oder mehr liegen. Dateien, die kleiner als etwa 900 Byte sind, werden im Verzeichniseintrag der MFT gespeichert. ⓘ

Vorteile

Nutzer von schnellen Mehrkernprozessoren werden durch die Komprimierung ihrer Anwendungen und Daten eine Verbesserung der Anwendungsgeschwindigkeit sowie eine Verringerung des beanspruchten Speicherplatzes feststellen. Selbst wenn SSD-Controller bereits Daten komprimieren, kommt es zu einer Verringerung der E/As, da weniger Daten übertragen werden. ⓘ

Nach Untersuchungen des NTFS-Entwicklungsteams von Microsoft sind 50-60 GB eine vernünftige Maximalgröße für eine komprimierte Datei auf einem NTFS-Datenträger mit einer Cluster- (Block-) Größe von 4 KB (Standard). Diese vernünftige Maximalgröße nimmt für Volumes mit kleineren Clustergrößen stark ab. ⓘ

Nachteile

Große komprimierbare Dateien werden stark fragmentiert, da jeder Brocken, der kleiner als 64 KB ist, ein Fragment wird. Flash-Speicher, wie z. B. SSD-Laufwerke, haben nicht die Kopfbewegungsverzögerungen und die hohe Zugriffszeit mechanischer Festplattenlaufwerke, so dass die Fragmentierung nur einen geringeren Nachteil hat. ⓘ

Wenn Systemdateien, die beim Booten benötigt werden (z. B. Treiber, NTLDR, winload.exe oder BOOTMGR), komprimiert werden, kann es vorkommen, dass das System nicht korrekt startet, weil die Dekomprimierungsfilter noch nicht geladen sind. Spätere Editionen von Windows lassen die Komprimierung wichtiger Systemdateien nicht mehr zu. ⓘ

Systemkomprimierung

Seit Windows 10 hat Microsoft ein neues Dateikomprimierungsschema eingeführt, das auf dem XPRESS-Algorithmus mit 4K/8K/16K-Blockgröße und dem LZX-Algorithmus basiert; beides sind Varianten von LZ77, die mit Huffman-Entropiekodierung und Bereichskodierung aktualisiert wurden, die LZNT1 fehlten. Diese Kompressionsalgorithmen wurden aus dem Windows Imaging Format (WIM-Datei) übernommen. ⓘ

Das neue Komprimierungsschema wird von der CompactOS-Funktion verwendet, die die Festplattennutzung durch Komprimierung von Windows-Systemdateien reduziert. CompactOS ist keine Erweiterung der NTFS-Dateikomprimierung und verwendet nicht das Attribut "komprimiert"; stattdessen wird für jede komprimierte Datei ein Reparse-Punkt mit einem WOF-Tag (Windows Overlay Filter) gesetzt, aber die eigentlichen Daten werden in einem alternativen Datenstrom mit dem Namen "WofCompressedData" gespeichert, der von einem WOF-Dateisystem-Filtertreiber im laufenden Betrieb dekomprimiert wird, und die Hauptdatei ist eine leere Sparse-Datei. Die Hauptdatei ist eine leere Sparse-Datei. Dieses Design ist für den reinen Lesezugriff gedacht, so dass jedes Schreiben auf komprimierte Dateien zu einer automatischen Dekomprimierung führt. ⓘ

Die CompactOS-Komprimierung ist für OEMs gedacht, die Betriebssystem-Images mit der Option /kompakt Flagge des DISM Werkzeugs im Windows ADK vorbereiten, aber sie kann auch manuell pro Datei mit der Option /exe Flagge des kompakt Befehl aktiviert werden. Der CompactOS-Algorithmus vermeidet die Fragmentierung von Dateien, indem er komprimierte Daten im Gegensatz zur NTFS-Komprimierung in zusammenhängend zugewiesenen Chunks schreibt. ⓘ

Die CompactOS-Dateikomprimierung ist eine verbesserte Version der WIMBoot-Funktion, die in Windows 8.1 eingeführt wurde. WIMBoot reduziert die Festplattennutzung von Windows, indem Systemdateien in einem komprimierten WIM-Image auf einer separaten versteckten Festplattenpartition gespeichert werden. Ähnlich wie bei CompactOS enthalten Windows-Systemverzeichnisse nur spärliche Dateien, die durch einen Reparse-Punkt mit einem WOF-Tag gekennzeichnet sind, und der Windows-Overlay-Filtertreiber dekomprimiert die Dateiinhalte on-the-fly aus dem WIM-Image. WIMBoot ist jedoch weniger effektiv als CompactOS, da neue aktualisierte Versionen von Systemdateien in die Systempartition geschrieben werden müssen, was Speicherplatz verbraucht. ⓘ

Sparse-Dateien

Eine spärliche Datei: Leere Bytes müssen nicht gespeichert werden und können daher durch Metadaten dargestellt werden. ⓘ

Sparse-Dateien sind Dateien, die mit leeren Segmenten durchsetzt sind, für die kein tatsächlicher Speicherplatz verwendet wird. Für die Anwendungen sieht die Datei wie eine gewöhnliche Datei aus, wobei leere Bereiche als mit Nullen gefüllte Bereiche angesehen werden; das Dateisystem führt eine interne Liste solcher Bereiche für jede Sparse-Datei. Eine Sparse-Datei enthält nicht notwendigerweise Sparse-Nullen-Bereiche; das Attribut "Sparse-Datei" bedeutet lediglich, dass die Datei diese enthalten darf. ⓘ

Datenbankanwendungen können zum Beispiel Sparse-Dateien verwenden. Wie bei komprimierten Dateien wird die tatsächliche Größe von Sparse-Dateien bei der Festlegung der Kontingentgrenzen nicht berücksichtigt. ⓘ

Volumen-Schattenkopie

Der Volume Shadow Copy Service (VSS) bewahrt historische Versionen von Dateien und Ordnern auf NTFS-Volumes auf, indem er alte, neu überschriebene Daten mittels Copy-on-Write-Technik in die Schattenkopie kopiert. Der Benutzer kann später eine frühere Version wiederherstellen lassen. Dies ermöglicht es auch Datensicherungsprogrammen, Dateien zu archivieren, die gerade vom Dateisystem verwendet werden. ⓘ

Mit Windows Vista wurden auch dauerhafte Schattenkopien zur Verwendung mit den Funktionen Systemwiederherstellung und Vorherige Versionen eingeführt. Persistente Schattenkopien werden jedoch gelöscht, wenn ein älteres Betriebssystem das NTFS-Volume mountet. Dies geschieht, weil das ältere Betriebssystem das neuere Format der persistenten Schattenkopien nicht versteht. ⓘ

Vorgänge

Mit der Einführung von Windows Vista wurde das NTFS-Dateisystem um das Konzept atomarer Operationen (Transaktionen) erweitert. Dieses transaktionsbasierte NTFS (englisch Transactional NTFS; kurz: TxF) ermöglicht es Anwendungen, Dateioperationen atomar auszuführen. Veränderungen am Dateisystem werden also nur dann ausgeführt, wenn die gesamte Transaktion erfolgreich durchgeführt werden konnte. Zu einer Transaktion kann dabei eine Einzeloperation oder eine Abfolge von Dateioperationen gehören (beispielsweise das Erzeugen, Löschen oder Umbenennen einer oder mehrerer Dateien bzw. Verzeichnisse). ⓘ

Transactional NTFS wurde auf Basis des ebenfalls mit Windows Vista eingeführten Kernel Transaction Manager (KTM) implementiert, der Transaktionen auf der Ebene des Kernels ermöglicht. Es erweitert die bereits in vorigen NTFS-Versionen enthaltene Journal-Funktionalität, die sich auf die Integrität der Strukturen des Dateisystems beschränkt, um folgende Möglichkeiten:

• Atomare Operationen auf Einzeldateien:

Ein Beispiel hierfür ist das Speichern einer Datei durch eine Anwendung: Kam es bislang während des Schreibvorgangs zu einem Programm- oder Rechnerabsturz, wurde unter früheren NTFS-Versionen nur ein Teil der Daten geschrieben, was zu einer unvollständigen Datei führen konnte. Dies war insbesondere problematisch, wenn eine frühere Dateiversion ersetzt bzw. überschrieben werden sollte – Datenverlust war die Folge.

• Atomare Operationen, die mehrere Dateien umfassen:

Wenn eine Applikation an mehreren Dateien gleichzeitig Veränderungen durchführen muss, können alle notwendigen Dateioperationen in einer Transaktion zusammengefasst und eine Dateninkonsistenz im Falle eines Fehlers vermieden werden.

• Atomare Operationen über Rechnergrenzen hinweg:

Die Durchführung gleicher Operationen auf mehreren Rechnern ist eine übliche administrative Aufgabe; beispielsweise in einem Rechnerverbund eines Unternehmens. Transactional NTFS interagiert mit dem Distributed Transaction Coordinator (DTC) und stellt sicher, dass Änderungen erfolgreich auf allen beteiligten Rechnern, die Transactional NTFS unterstützen, durchgeführt werden konnten (z. B. die zentrale Synchronisation mehrerer Arbeitsplatzrechner). ⓘ

Windows unterstützt Transaktionen ab Windows Vista bzw. Windows Server 2008. Mittlerweile empfiehlt Microsoft allerdings den Einsatz von Alternativen, die API muss damit als deprecated betrachtet und von einem Einsatz abgeraten werden. ⓘ

Es verwendet ähnliche Techniken wie bei Volume Shadow Copies (d. h. Copy-on-Write), um sicherzustellen, dass überschriebene Daten sicher zurückgesetzt werden können, und ein CLFS-Protokoll, um die Transaktionen zu markieren, die noch nicht übertragen wurden oder die zwar übertragen, aber noch nicht vollständig angewendet wurden (im Falle eines Systemabsturzes während einer Übertragung durch einen der Teilnehmer). ⓘ

Das transaktionale NTFS beschränkt Transaktionen nicht nur auf das lokale NTFS-Volume, sondern schließt auch andere transaktionale Daten oder Operationen an anderen Orten ein, z. B. Daten, die in separaten Volumes, in der lokalen Registrierung oder in SQL-Datenbanken gespeichert sind, oder die aktuellen Zustände von Systemdiensten oder Remote-Diensten. Diese Transaktionen werden netzwerkweit mit allen Teilnehmern koordiniert, die einen bestimmten Dienst, den DTC, nutzen, um sicherzustellen, dass alle Teilnehmer denselben Commit-Status erhalten, und um die Änderungen zu transportieren, die von einem beliebigen Teilnehmer bestätigt wurden (so dass die anderen ihre lokalen Caches für alte Daten ungültig machen oder ihre laufenden, noch nicht bestätigten Änderungen zurücksetzen können). Transactional NTFS ermöglicht beispielsweise die Erstellung netzwerkweiter konsistenter verteilter Dateisysteme, auch mit ihren lokalen Live- oder Offline-Caches. ⓘ

Kontingente

Festplattenkontingente wurden mit NTFS v3 eingeführt und ermöglichen es dem Administrator eines Computers, auf dem eine Windows-Version mit NTFS-Unterstützung läuft, einen Schwellenwert für den Speicherplatz festzulegen, den Benutzer verwenden dürfen. Außerdem können Administratoren auf diese Weise verfolgen, wie viel Speicherplatz jeder Benutzer verwendet. Ein Administrator kann eine bestimmte Menge an Festplattenspeicher festlegen, die ein Benutzer verwenden darf, bevor er eine Warnung erhält, und ihm dann den Zugriff verweigern, sobald er die Obergrenze erreicht hat. Festplattenkontingente berücksichtigen nicht die transparente Dateikomprimierung von NTFS, sollte diese aktiviert sein. Anwendungen, die die Menge an freiem Speicherplatz abfragen, sehen auch die Menge an freiem Speicherplatz, die dem Benutzer, der eine Quote hat, noch zur Verfügung steht. ⓘ

Reparse-Punkte

Die in NTFS v3 eingeführten NTFS-Reparse-Punkte werden verwendet, indem ein Reparse-Tag in das User-Space-Attribut einer Datei oder eines Verzeichnisses eingefügt wird. Microsoft bietet mehrere Standard-Tags an, darunter symbolische Links, Verzeichnisübergangspunkte und Volume-Mount-Punkte. Wenn der Objektmanager einen Dateisystemnamen analysiert und auf ein Reparse-Attribut stößt, wird er den Namen reparieren und die benutzergesteuerten Reparse-Daten an jeden Dateisystem-Filtertreiber weitergeben, der in Windows geladen ist. Jeder Filtertreiber prüft die Reparse-Daten, um festzustellen, ob sie mit dem Reparse-Punkt verbunden sind, und wenn der Filtertreiber eine Übereinstimmung feststellt, fängt er die Dateisystemanforderung ab und führt seine spezielle Funktionalität aus. ⓘ

Beschränkungen

Größenänderung

Ab Windows Vista hat Microsoft die Möglichkeit eingebaut, eine Partition zu verkleinern oder zu vergrößern. Diese Fähigkeit verschiebt jedoch keine Auslagerungsdateifragmente oder Dateien, die als nicht verschiebbar markiert wurden, so dass das Verkleinern eines Volumes oft das Verschieben oder Deaktivieren einer Auslagerungsdatei, des Indexes der Windows-Suche und einer von der Systemwiederherstellung verwendeten Schattenkopie erfordert. Verschiedene Tools von Drittanbietern sind in der Lage, die Größe von NTFS-Partitionen zu ändern. ⓘ

OneDrive

Seit 2017 verlangt Microsoft, dass sich die Dateistruktur von OneDrive auf einem NTFS-Laufwerk befindet. Dies liegt daran, dass die OneDrive Files On-Demand-Funktion NTFS-Reparse-Punkte verwendet, um Dateien und Ordner, die in OneDrive gespeichert sind, mit dem lokalen Dateisystem zu verknüpfen, wodurch die Datei oder der Ordner mit einer früheren Version von Windows, mit einem anderen NTFS-Dateisystemtreiber oder mit Dateisystem- und Sicherungsdienstprogrammen, die nicht für die Unterstützung aktualisiert wurden, unbrauchbar wird. ⓘ

Aufbau

NTFS besteht aus mehreren Komponenten: einem Partitions-Boot-Sektor (PBS), der Boot-Informationen enthält; der Master File Table, die eine Aufzeichnung aller Dateien und Ordner im Dateisystem speichert; einer Reihe von Metadateien, die helfen, Metadaten effizienter zu strukturieren; Datenströme und Sperrmechanismen. ⓘ

Intern verwendet NTFS B-Bäume, um Dateisystemdaten zu indizieren. Ein Dateisystemjournal wird verwendet, um die Integrität der Metadaten des Dateisystems zu gewährleisten, nicht aber den Inhalt der einzelnen Dateien. Systeme, die NTFS verwenden, sind im Vergleich zu FAT-Dateisystemen für ihre höhere Zuverlässigkeit bekannt. ⓘ

NTFS erlaubt eine beliebige Folge von 16-Bit-Werten für die Namenskodierung (z. B. Dateinamen, Streamnamen oder Indexnamen) außer 0x0000. Das bedeutet, dass UTF-16-Codeeinheiten unterstützt werden, aber das Dateisystem prüft nicht, ob eine Folge gültig ist (es erlaubt jede Folge kurzer Werte, die nicht auf die im Unicode-Standard enthaltenen beschränkt sind). Im Win32-Namensraum sind alle UTF-16-Codeeinheiten unabhängig von der Groß- und Kleinschreibung, während im POSIX-Namensraum die Groß- und Kleinschreibung beachtet wird. Dateinamen sind auf 255 UTF-16-Code-Einheiten begrenzt. Bestimmte Namen sind im Stammverzeichnis des Volumes reserviert und können nicht für Dateien verwendet werden. Dies sind $MFT, $MFTMirr, $LogFile, $Volume, $AttrDef, . (Punkt), $Bitmap, $Boot, $BadClus, $Secure, $UpCase und $Extend. . (dot) und $Extend sind beides Verzeichnisse, die anderen sind Dateien. Der NT-Kernel begrenzt vollständige Pfade auf 32.767 UTF-16-Codeeinheiten. Es gibt einige zusätzliche Beschränkungen für Codepunkte und Dateinamen. ⓘ

Partitions-Bootsektor (PBS)

Inhalt des NTFS-Bootsektors (Alle Werte außer Zeichenketten werden in Little-Endian-Reihenfolge gespeichert).

Byte-Offset	Feldlänge	Typischer Wert	Feldname		Zweck ⓘ
0x00	3 Bytes	0xEB5290	JMP-Anweisung		Bewirkt, dass die Ausführung nach den Datenstrukturen in diesem Bootsektor fortgesetzt wird.
0x03	8 Bytes	"NTFS" Wort "NTFS" gefolgt von vier Leerzeichen am Ende (0x20)	OEM-KENNUNG		Dies ist die magische Zahl, die anzeigt, dass es sich um ein NTFS-Dateisystem handelt.
0x0B	2 Bytes	0x0200	BPB	Bytes pro Sektor	Die Anzahl der Bytes in einem Plattensektor.
0x0D	1 Byte	0x08		Sektoren pro Cluster	Die Anzahl der Sektoren in einem Cluster. Wenn der Wert größer als 0x80 ist, ist die Anzahl der Sektoren 2 hoch dem absoluten Wert, wenn dieses Feld als negativ angesehen wird.
0x0E	2 Bytes	0x0000		Reservierte Sektoren, unbenutzt
0x10	3 Bytes	0x000000		Unbenutzt	Dieses Feld ist immer 0
0x13	2 Bytes	0x0000		Unbenutzt von NTFS	Dieses Feld ist immer 0
0x15	1 Byte	0xF8		Medien Deskriptor	Der Typ des Laufwerks. 0xF8 wird verwendet, um ein Festplattenlaufwerk zu bezeichnen (im Gegensatz zu den verschiedenen Floppy-Größen).
0x16	2 Bytes	0x0000		Unbenutzt	Dieses Feld ist immer 0
0x18	2 Bytes	0x003F		Sektoren pro Spur	Die Anzahl der Plattensektoren in einer Laufwerksspur.
0x1A	2 Bytes	0x00FF		Anzahl der Köpfe	Die Anzahl der Köpfe auf dem Laufwerk.
0x1C	4 Bytes	0x0000003F		Versteckte Sektoren	Die Anzahl der Sektoren, die der Partition vorausgehen.
0x20	4 Bytes	0x00000000		Unbenutzt	Wird von NTFS nicht verwendet
0x24	4 Bytes	0x00800080	EBPB	Unbenutzt	Wird von NTFS nicht verwendet
0x28	8 Bytes	0x00000000007FF54A		Sektoren gesamt	Die Partitionsgröße in Sektoren.
0x30	8 Bytes	0x0000000000000004		$MFT-Clusternummer	Der Cluster, der die Master File Table enthält
0x38	8 Bytes	0x000000000007FF54		$MFTMirr Clusternummer	Der Cluster, der eine Sicherung der Master File Table enthält
0x40	1 Byte	0xF6		Bytes oder Cluster pro Dateisatzsegment	Ein positiver Wert gibt die Anzahl der Cluster in einem File Record Segment an. Ein negativer Wert gibt die Anzahl der Bytes in einem File Record Segment an. In diesem Fall ist die Größe 2 hoch dem absoluten Wert. (0xF6 = -10 → 210 = 1024).
0x41	3 Bytes	0x000000		Unbenutzt	Dieses Feld wird von NTFS nicht verwendet.
0x44	1 Byte	0x01		Bytes oder Cluster pro Indexpuffer	Ein positiver Wert bezeichnet die Anzahl von Clustern in einem Indexpuffer. Ein negativer Wert bezeichnet die Anzahl der Bytes und es wird derselbe Algorithmus für negative Zahlen verwendet wie bei "Bytes oder Cluster pro Dateisatzsegment".
0x45	3 Bytes	0x000000		Unbenutzt	Dieses Feld wird von NTFS nicht verwendet.
0x48	8 Bytes	0x1C741BC9741BA514		Volume-Seriennummer	Eine eindeutige Zufallszahl, die dieser Partition zugewiesen wird, um die Dinge zu organisieren.
0x50	4 Bytes	0x00000000		Prüfsumme, unbenutzt	Angeblich eine Prüfsumme.
0x54	426 Bytes		Bootstrap-Code		Der Code, der den Rest des Betriebssystems lädt. Darauf verweisen die ersten 3 Bytes dieses Sektors.
0x01FE	2 Bytes	0xAA55	Markierung für das Ende des Sektors		Diese Markierung zeigt an, dass dies ein gültiger Bootsektor ist.

Dieses Bootpartitionsformat basiert grob auf dem früheren FAT-Dateisystem, aber die Felder befinden sich an anderen Stellen. Einige dieser Felder, insbesondere die Felder "Sektoren pro Spur", "Anzahl der Köpfe" und "versteckte Sektoren" können auf Laufwerken, auf denen sie entweder keinen Sinn ergeben oder nicht ermittelbar sind, Dummy-Werte enthalten. ⓘ

Das Betriebssystem betrachtet zunächst die 8 Bytes bei 0x30, um die Clusternummer der $MFT zu ermitteln, und multipliziert diese Zahl dann mit der Anzahl der Sektoren pro Cluster (1 Byte bei 0x0D). Dieser Wert ist der Sektor-Offset (LBA) zur $MFT, der im Folgenden beschrieben wird. ⓘ

Master File Table

In NTFS werden alle Datei-, Verzeichnis- und Metadateidaten - Dateiname, Erstellungsdatum, Zugriffsrechte (mit Hilfe von Zugriffskontrolllisten) und Größe - als Metadaten in der Master File Table (MFT) gespeichert. Dieser abstrakte Ansatz ermöglichte das einfache Hinzufügen von Dateisystemfunktionen während der Entwicklung von Windows NT - ein Beispiel ist das Hinzufügen von Feldern für die Indexierung, die von der Active Directory-Software verwendet werden. Dies ermöglicht es auch schneller Dateisuch-Software, benannte lokale Dateien und Ordner, die in der MFT enthalten sind, sehr schnell zu finden, ohne dass ein anderer Index erforderlich ist. ⓘ

Die MFT-Struktur unterstützt Algorithmen, die die Fragmentierung der Festplatte minimieren. Ein Verzeichniseintrag besteht aus einem Dateinamen und einer "Datei-ID" (analog zur Inode-Nummer), d. h. der Datensatznummer, die die Datei in der Master File Table repräsentiert. Die Datei-ID enthält auch eine Wiederverwendungszahl, um veraltete Verweise zu erkennen. Während dies stark der W_FID von Files-11 ähnelt, unterscheiden sich andere NTFS-Strukturen radikal. ⓘ

Eine Teilkopie der MFT, die so genannte MFT-Spiegelung, wird gespeichert, um im Falle einer Beschädigung verwendet zu werden. Wenn der erste Datensatz der MFT beschädigt ist, liest NTFS den zweiten Datensatz, um die MFT-Spiegeldatei zu finden. Die Speicherorte für beide Dateien werden im Bootsektor gespeichert. ⓘ

Metadateien

NTFS enthält mehrere Dateien, die das Dateisystem definieren und organisieren. In jeder Hinsicht sind die meisten dieser Dateien wie jede andere Benutzerdatei strukturiert ($Volume ist die eigentümlichste), aber sie sind für Dateisystem-Clients nicht von direktem Interesse. Diese Metadateien definieren Dateien, sichern kritische Dateisystemdaten, puffern Dateisystemänderungen, verwalten die Zuweisung von freiem Speicherplatz, erfüllen die Erwartungen des BIOS, verfolgen fehlerhafte Zuweisungseinheiten und speichern Sicherheits- und Speicherplatzinformationen. Alle Inhalte befinden sich in einem unbenannten Datenstrom, sofern nicht anders angegeben. ⓘ

MFT (die Einträge 0-26 sind die NTFS-Metadateien)

Segment-Nummer	Name der Datei	Zweck ⓘ
0	$MFT	Beschreibt alle Dateien auf dem Datenträger, einschließlich Dateinamen, Zeitstempel, Streamnamen und Listen von Clusternummern, in denen sich Datenströme befinden, Indizes, Sicherheitskennungen und Dateiattribute wie "schreibgeschützt", "komprimiert", "verschlüsselt" usw.
1	$MFTMirr	Duplikat der ersten wichtigen Einträge von $MFT, normalerweise 4 Einträge (4 Kilobyte).
2	$LogDatei	Enthält das Transaktionsprotokoll der Änderungen der Metadaten des Dateisystems.
3	$Volumen	Enthält Informationen über den Datenträger, nämlich die Datenträger-Objektkennung, die Datenträger-Kennzeichnung, die Dateisystemversion und Datenträger-Flags (gemountet, chkdsk angefordert, Größenänderung von $LogFile angefordert, gemountet auf NT 4, Aktualisierung der Datenträger-Seriennummer, Anforderung eines Struktur-Upgrades). Diese Daten werden nicht in einem Datenstrom, sondern in speziellen MFT-Attributen gespeichert: Falls vorhanden, wird eine Datenträger-Objekt-ID in einem $OBJECT_ID-Datensatz gespeichert; die Datenträgerbezeichnung wird in einem $VOLUME_NAME-Datensatz gespeichert, und die übrigen Datenträgerdaten befinden sich in einem $VOLUME_INFORMATION-Datensatz. Hinweis: Die Seriennummer des Datenträgers wird in der Datei $Boot (unten) gespeichert.
4	$AttrDef	Eine Tabelle mit MFT-Attributen, die numerische Bezeichner mit Namen verknüpft.
5	.	Wurzelverzeichnis. Verzeichnisdaten werden in den Attributen $INDEX_ROOT und $INDEX_ALLOCATION gespeichert, die beide $I30 heißen.
6	$Bitmap	Ein Array von Bit-Einträgen: jedes Bit zeigt an, ob der entsprechende Cluster verwendet (zugewiesen) oder frei (zur Zuweisung verfügbar) ist.
7	$Boot	Volume-Boot-Record (VBR). Diese Datei befindet sich immer in den ersten Clustern auf dem Volume. Sie enthält Bootstrap-Code (siehe NTLDR/BOOTMGR) und einen BIOS-Parameterblock mit einer Volume-Seriennummer und Clusternummern von $MFT und $MFTMirr.
8	$BadClus	Eine Datei, die alle Cluster enthält, die als fehlerhafte Sektoren gekennzeichnet sind. Diese Datei vereinfacht die Cluster-Verwaltung durch das chkdsk-Dienstprogramm, da sie sowohl als Ablage für neu entdeckte defekte Sektoren als auch zur Identifizierung nicht referenzierter Cluster dient. Diese Datei enthält zwei Datenströme, selbst auf Datenträgern ohne fehlerhafte Sektoren: ein unbenannter Strom enthält fehlerhafte Sektoren - bei perfekten Datenträgern hat er eine Länge von Null; der zweite Strom heißt $Bad und enthält alle Cluster auf dem Datenträger, die nicht im ersten Strom enthalten sind.
9	$Secure	Zugriffskontrolllisten-Datenbank, die den Overhead reduziert, der entsteht, wenn viele identische ACLs mit jeder Datei gespeichert werden, indem diese ACLs nur in dieser Datenbank eindeutig gespeichert werden (enthält zwei Indizes: $SII (Standard_Information ID) und $SDH (Security Descriptor Hash), die den Stream namens $SDS indizieren, der die eigentliche ACL-Tabelle enthält).
10	$UpCase	Eine Tabelle mit Unicode-Großbuchstaben, um die Groß-/Kleinschreibung in Win32- und DOS-Namensräumen zu berücksichtigen.
11	$Erweiterung	Ein Dateisystemverzeichnis, das verschiedene optionale Erweiterungen enthält, wie $Quota, $ObjId, $Reparse oder $UsnJrnl.
12–23	Reserviert für $MFT-Erweiterungseinträge. Erweiterungseinträge sind zusätzliche MFT-Datensätze, die zusätzliche Attribute enthalten, die nicht in den primären Datensatz passen. Dies kann der Fall sein, wenn die Datei ausreichend fragmentiert ist, viele Streams, lange Dateinamen, komplexe Sicherheit oder andere seltene Situationen aufweist.
24	$Erweiterung\$Quota	Enthält Plattenkontingentinformationen. Enthält zwei Indexwurzeln, die $O und $Q heißen.
25	$Erweiterung\$ObjId	Enthält Informationen zur Linkverfolgung. Enthält eine Indexwurzel und eine Zuordnung namens $O.
26	$Erweiterung\$Reparse	Enthält Reparse-Punkt-Daten (wie symbolische Links). Enthält eine Indexwurzel und eine Zuweisung namens $R.
27–	Beginn von regulären Dateieinträgen.

Diese Metadateien werden von Windows speziell behandelt, direkt vom NTFS.SYS-Treiber gehandhabt und sind schwer direkt einzusehen: Es werden spezielle, eigens dafür entwickelte Tools benötigt. Ab Windows 7 verbietet der NTFS-Treiber den Benutzerzugriff vollständig, was zu einem BSoD führt, sobald ein Versuch unternommen wird, eine Metadaten-Datei auszuführen. Ein solches Tool ist nfi.exe ("NTFS File Sector Information Utility"), das als Teil der Microsoft "OEM Support Tools" kostenlos verteilt wird. Um beispielsweise Informationen über das "$MFT"-Master File Table Segment zu erhalten, wird der folgende Befehl verwendet: nfi.exe c:\$MFT Eine andere Möglichkeit, die Beschränkung zu umgehen, besteht darin, den Dateimanager von 7-Zip zu verwenden und den NTFS-Pfad auf niedriger Ebene \\.\X:\ (wobei X:\ einem beliebigen Laufwerk/Partition entspricht) aufzurufen. Hier erscheinen 3 neue Ordner: $EXTEND, [DELETED] (ein Pseudo-Ordner, den 7-Zip verwendet, um aus dem Dateisystem gelöschte Dateien zur Ansicht anzuhängen) und [SYSTEM] (ein weiterer Pseudo-Ordner, der alle NTFS-Metadaten enthält). Dieser Trick kann von Wechseldatenträgern (USB-Flash-Laufwerken, externen Festplatten, SD-Karten usw.) innerhalb von Windows angewendet werden, aber um dies auf der aktiven Partition zu tun, ist Offline-Zugriff erforderlich (nämlich WinRE). ⓘ

Attributlisten, Attribute und Streams

Für jede im MFT-Datensatz beschriebene Datei (oder jedes Verzeichnis) gibt es eine lineare Sammlung von Stream-Deskriptoren (auch Attribute genannt), die in einem oder mehreren MFT-Datensätzen (die die so genannte Attributliste enthalten) zusammengefasst sind, mit zusätzlichen Auffüllungen, um die feste Größe von 1 KB jedes MFT-Datensatzes auszufüllen, und die die mit dieser Datei verbundenen effektiven Streams vollständig beschreiben. ⓘ

Jedes Attribut hat einen Attributtyp (eine Ganzzahl mit fester Größe, die auf eine Attributdefinition in der Datei $AttrDef abgebildet wird), einen optionalen Attributnamen (z. B. als Name für einen alternativen Datenstrom) und einen Wert, der in einer Folge von Bytes dargestellt wird. Bei NTFS werden die Standarddaten von Dateien, die alternativen Datenströme oder die Indexdaten für Verzeichnisse als Attribute gespeichert. ⓘ

Gemäß $AttrDef können einige Attribute entweder resident oder nicht-resident sein. Das $DATA-Attribut, das Dateidaten enthält, ist ein solches Beispiel. Wenn das Attribut resident ist (was durch ein Flag dargestellt wird), wird sein Wert direkt im MFT-Datensatz gespeichert. Andernfalls werden den Daten Cluster zugewiesen, und die Informationen zum Speicherort der Cluster werden als Datenläufe im Attribut gespeichert.

• Für jede Datei in der MFT müssen die durch Attributtyp und Attributname identifizierten Attribute eindeutig sein. Außerdem hat NTFS einige Ordnungsbeschränkungen für diese Attribute.
• Es gibt einen vordefinierten Null-Attributtyp, der verwendet wird, um das Ende der Liste der Attribute in einem MFT-Datensatz anzuzeigen. Es muss als letztes Attribut im Datensatz vorhanden sein (der gesamte danach verfügbare Speicherplatz wird ignoriert und besteht nur aus Auffüllungsbytes, um der Datensatzgröße in der MFT zu entsprechen).
• Einige Attributtypen sind obligatorisch und müssen in jedem MFT-Datensatz vorhanden sein, außer bei unbenutzten Datensätzen, die einfach durch Null-Attributtypen angezeigt werden.
  • Dies ist der Fall für das Attribut $STANDARD_INFORMATION, das als Datensatz fester Größe gespeichert wird und die Zeitstempel und andere grundlegende Ein-Bit-Attribute enthält (kompatibel mit denen, die von FAT in DOS oder Windows 9x verwaltet werden).
• Einige Attributtypen können keinen Namen haben und müssen anonym bleiben.
  • Dies ist der Fall für die Standardattribute oder für den bevorzugten NTFS-Attributtyp "Dateiname" oder den Attributtyp "Kurzer Dateiname", wenn dieser ebenfalls vorhanden ist (für die Kompatibilität mit DOS-ähnlichen Anwendungen, siehe unten). Es ist auch möglich, dass eine Datei nur einen kurzen Dateinamen enthält. In diesem Fall ist es der bevorzugte Dateiname, wie er im Windows Explorer aufgelistet wird.
  • Die in der Attributliste gespeicherten Dateinamensattribute machen die Datei nicht unmittelbar über das hierarchische Dateisystem zugänglich. Vielmehr müssen alle Dateinamen separat in mindestens einem anderen Verzeichnis auf demselben Datenträger indiziert sein. Dort muss sie ihren eigenen MFT-Eintrag und ihre eigenen Sicherheitsdeskriptoren und Attribute haben, die auf die MFT-Eintragsnummer für diese Datei verweisen. Auf diese Weise kann dieselbe Datei oder dasselbe Verzeichnis mehrmals von mehreren Containern auf demselben Datenträger aus "hardverlinkt" werden, möglicherweise mit unterschiedlichen Dateinamen.
• Der Standard-Datenstrom einer regulären Datei ist ein Strom vom Typ $DATA, aber mit einem anonymen Namen, und die ADS sind ähnlich, müssen aber benannt werden.
• Der Standarddatenstrom von Verzeichnissen hingegen hat einen eindeutigen Typ, ist aber nicht anonym: Er hat einen Attributnamen ("$I30" in NTFS 3+), der sein Indizierungsformat widerspiegelt. ⓘ

Alle Attribute einer bestimmten Datei können mit dem Programm nfi.exe ("NTFS File Sector Information Utility") angezeigt werden, das als Teil der Microsoft "OEM Support Tools" kostenlos verteilt wird. ⓘ

Windows-Systemaufrufe können alternative Datenströme verarbeiten. Je nach Betriebssystem, Dienstprogramm und entferntem Dateisystem können bei einer Dateiübertragung Datenströme stillschweigend entfernt werden. Eine sichere Methode zum Kopieren oder Verschieben von Dateien ist die Verwendung der Systemaufrufe BackupRead und BackupWrite, die es Programmen ermöglichen, Datenströme aufzuzählen, zu überprüfen, ob jeder Datenstrom auf den Zieldatenträger geschrieben werden soll, und unerwünschte Datenströme wissentlich zu überspringen. ⓘ

Residente vs. nicht-residente Attribute

Um die Speicherung zu optimieren und den E/A-Overhead für den sehr häufigen Fall von Attributen mit sehr kleinem zugehörigen Wert zu reduzieren, zieht es NTFS vor, den Wert innerhalb des Attributs selbst zu platzieren (wenn die Größe des Attributs dann nicht die maximale Größe eines MFT-Datensatzes überschreitet), anstatt den MFT-Datensatzplatz für die Auflistung von Clustern zu verwenden, die die Daten enthalten; in diesem Fall speichert das Attribut die Daten nicht direkt, sondern speichert lediglich eine Zuordnungsabbildung (in Form von Datenläufen), die auf die tatsächlichen Daten verweist, die an anderer Stelle auf dem Datenträger gespeichert sind. Wenn auf den Wert direkt vom Attribut aus zugegriffen werden kann, spricht man von "residenten Daten" (bei Computerforensikern). Die passende Datenmenge hängt stark von den Dateieigenschaften ab, aber 700 bis 800 Byte sind bei Single-Stream-Dateien mit nicht langen Dateinamen und ohne ACLs üblich.

• Einige Attribute (z. B. der bevorzugte Dateiname, die grundlegenden Dateiattribute) können nicht als nicht-residente Attribute festgelegt werden. Bei nicht ortsgebundenen Attributen muss ihre Zuordnungsliste in MFT-Datensätze passen.
• Verschlüsselt durch NTFS, spärliche Datenströme oder komprimierte Datenströme können nicht resident gemacht werden.
• Das Format der Allokationskarte für nicht residente Attribute hängt von ihrer Fähigkeit ab, Sparse-Datenspeicher zu unterstützen. In der aktuellen NTFS-Implementierung kann ein nicht-residenter Datenstrom, sobald er als Sparse markiert und konvertiert wurde, nicht mehr in nicht-sparse Daten zurückverwandelt werden, d. h. er kann nicht wieder resident werden, es sei denn, diese Daten werden vollständig abgeschnitten, wodurch die Sparse-Zuordnungsabbildung vollständig verworfen wird.
• Wenn ein nicht-residentes Attribut so fragmentiert ist, dass seine effektive Zuordnungsliste nicht vollständig in einen MFT-Datensatz passt, speichert NTFS das Attribut in mehreren Datensätzen. Der erste von ihnen wird als Basisdatensatz bezeichnet, während die anderen als Erweiterungsdatensätze bezeichnet werden. NTFS erstellt ein spezielles Attribut $ATTRIBUTE_LIST, um Informationen zu speichern, die verschiedene Teile des langen Attributs auf die MFT-Datensätze abbilden, was bedeutet, dass die Zuordnungsliste in mehrere Datensätze aufgeteilt werden kann. Das Attribut $ATTRIBUTE_LIST selbst kann auch nicht-resident sein, aber seine eigene Zuordnungsliste muss in einen MFT-Datensatz passen.
• Wenn es zu viele Attribute für eine Datei gibt (einschließlich ADSs, erweiterter Attribute oder Sicherheitsdeskriptoren), so dass sie nicht alle in einen MFT-Datensatz passen, können auch Erweiterungsdatensätze verwendet werden, um die anderen Attribute zu speichern, wobei das gleiche Format wie im Basis-MFT-Datensatz verwendet wird, aber ohne die Platzbeschränkungen eines MFT-Datensatzes. ⓘ

Die Zuordnungskarte wird in Form von Datenläufen mit komprimierter Kodierung gespeichert. Jeder Datenlauf stellt eine zusammenhängende Gruppe von Clustern dar, die den Attributwert speichern. Bei Dateien auf einem Multi-GB-Datenträger kann jeder Eintrag mit 5 bis 7 Byte kodiert werden, was bedeutet, dass ein 1 KB großer MFT-Datensatz etwa 100 solcher Datenläufe speichern kann. Da die $ATTRIBUTE_LIST jedoch auch eine Größenbeschränkung hat, ist es gefährlich, mehr als 1 Million Fragmente einer einzelnen Datei auf einem NTFS-Volume zu haben, was auch bedeutet, daß es im allgemeinen keine gute Idee ist, NTFS-Kompression für eine Datei zu verwenden, die größer als 10 GB ist. ⓘ

Der NTFS-Dateisystemtreiber wird manchmal versuchen, die Daten einiger der Attribute, die nicht resident gemacht werden können, in die Cluster zu verschieben, und wird auch versuchen, die in Clustern gespeicherten Daten zurück zum Attribut innerhalb des MFT-Datensatzes zu verschieben, basierend auf Prioritäts- und bevorzugten Ordnungsregeln und Größenbeschränkungen. ⓘ

Da residente Dateien nicht direkt Cluster ("Zuordnungseinheiten") belegen, ist es möglich, dass ein NTFS-Volume mehr Dateien auf einem Volume enthält, als es Cluster gibt. Ein Beispiel: Eine 74,5 GB große NTFS-Partition hat 19.543.064 Cluster mit 4 KB. Abzüglich der Systemdateien (eine 64 MB große Protokolldatei, eine 2.442.888 Byte große Bitmap-Datei und etwa 25 Cluster mit festem Overhead) bleiben 19.526.158 Cluster für Dateien und Indizes frei. Da es vier MFT-Datensätze pro Cluster gibt, könnte dieses Volume theoretisch fast 4 × 19.526.158 = 78.104.632 residente Dateien enthalten. ⓘ

Opportunistische Sperren

Opportunistische Dateisperren (Oplocks) ermöglichen es den Clients, ihre Pufferungsstrategie für eine bestimmte Datei oder einen bestimmten Datenstrom zu ändern, um die Leistung zu steigern und die Netznutzung zu verringern. Oplocks gelten für den jeweiligen offenen Stream einer Datei und haben keinen Einfluss auf Oplocks in einem anderen Stream. ⓘ

Oplocks können für den transparenten Zugriff auf Dateien im Hintergrund verwendet werden. Ein Netzwerk-Client kann es vermeiden, Informationen in eine Datei auf einem entfernten Server zu schreiben, wenn kein anderer Prozess auf die Daten zugreift, oder er kann Read-Ahead-Daten puffern, wenn kein anderer Prozess Daten schreibt. ⓘ

Windows unterstützt vier verschiedene Arten von Oplocks:

• Oplock der Stufe 2 (oder gemeinsames Oplock): mehrere Leser, keine Schreiber (d. h. Lese-Caching).
• Level 1 (oder exklusives) Oplock: exklusiver Zugriff mit beliebiger Pufferung (d.h. Lese- und Schreibcaching).
• Batch oplock (ebenfalls exklusiv): ein Stream wird auf dem Server geöffnet, aber auf dem Client-Rechner geschlossen (d. h. Lese-, Schreib- und Handle-Caching).
• Filter-Oplock (ebenfalls exklusiv): Anwendungen und Dateisystemfilter können sich "zurückziehen", wenn andere versuchen, auf denselben Stream zuzugreifen (d. h. Lese- und Schreibcaching) (seit Windows 2000) ⓘ

Opportunistische Sperren wurden in Windows 7 und Windows Server 2008 R2 mit Oplock-Schlüsseln pro Client verbessert. ⓘ

Zeit

Windows NT und seine Nachfahren speichern interne Zeitstempel in UTC und nehmen die entsprechenden Konvertierungen für Anzeigezwecke vor; alle NTFS-Zeitstempel sind in UTC. ⓘ

Aus historischen Gründen wird die Zeit in allen Windows-Versionen, die NTFS nicht unterstützen, intern als Ortszeit gespeichert, so auch in allen Dateisystemen - außer NTFS -, die von aktuellen Windows-Versionen unterstützt werden. Das bedeutet, dass das Betriebssystem beim Kopieren oder Verschieben von Dateien zwischen NTFS- und Nicht-NTFS-Partitionen die Zeitstempel im laufenden Betrieb umrechnen muss. Wenn jedoch einige Dateien verschoben werden, während die Sommerzeit gilt, und andere Dateien verschoben werden, während die Standardzeit gilt, kann es zu Unklarheiten bei der Konvertierung kommen. Infolgedessen kann es vorkommen, dass die Zeitstempel einiger Dateien um eine Stunde falsch sind, insbesondere kurz nach einem der Tage, an denen die lokale Zeitzone umgestellt wird. Aufgrund der unterschiedlichen Umsetzung der Sommerzeit in den verschiedenen Ländern kann dies zu einem möglichen Zeitstempelfehler von bis zu 4 Stunden in einem beliebigen Zeitraum von 12 Monaten führen. ⓘ

Unterschiede gegenüber dem Dateisystem FAT

Ab NTFS 2.X

• Datenverschlüsselung (nur auf Dateiebene) ⓘ

Ab NTFS 3.X

Analysepunkte

Analysepunkte (englisch auch reparsepoint genannt) stellen eine flexible Erweiterung für das Dateisystem dar, indem es Dateisystemeinträge mit Funktionen verknüpft. Diese können auf vielfältige Art verwendet – so etwa über den Befehl fsutil verwaltet – und auch in zukünftigen Versionen erweitert werden. Ein Dateisystemtreiber, der eine bestimmte Art Analysepunkt nicht kennt, führt diesen nicht aus. Beim Zugriff auf einen Analysepunkt werden die funktionsspezifischen Analysedaten dynamisch durch die entsprechende Funktion ausgewertet (daher „Analyse“). Dies impliziert, dass eine solche Analyse auch fehlschlagen kann und ein Zugriff auf die durch den Analysepunkt bereitgestellten Daten (möglicherweise durch aktuelle, vorübergehende Umstände) nicht möglich ist. ⓘ

Folgende Funktionen werden derzeit von NTFS unterstützt:

• Abzweigungspunkte, um Verzeichnisverbindungen mit Verzeichnissen zu verbinden.
• Bereitstellungspunkte, um logische Datenträger in andere Verzeichnisse einzubinden.
• Symbolische Verknüpfungen, um Dateieinträge mit Dateien zu verknüpfen. Diese wurden mit Vista eingeführt und unterstützen, anders als die zuvor genannten Analysepunkte, auch Verweise zu nicht lokalen Objekten – sie können also (ebenso wie die Bereitstellungspunkte) über (physische) Datenträgergrenzen hinaus verweisen. ⓘ

Unterstützung durch andere Betriebssysteme

Da es sich bei NTFS um ein proprietäres Dateisystem handelt, ist ein Zugriff durch andere Betriebssysteme als die der Windows-NT-Reihe unter Umständen nur in begrenztem Umfang möglich. ⓘ