NTFS

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Master File Table)
Zur Navigation springen Zur Suche springen
NTFS
Hersteller Microsoft
Vollständige Bezeichnung New Technology File System
Erstveröffentlichung Juli 1993 (Windows NT 3.1)
Partitionskennung 0x07 (MBR)
EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (GPT)
Technische Umsetzung
Verzeichnisse B+-Baum
Dateien Bitmap/Extents
Defektblockliste Bitmap/Extents
Maximalwerte
Größe einer Datei 16 TiB in der aktuellen Umsetzung (16 EiB konzeptbedingt) = ca. 17,1 TB bzw. 18,0 EB
Anzahl aller Dateien 4.294.967.295 (232-1)
Länge des Dateinamens 255 Zeichen
Größe des Dateisystems 256 TiB in der aktuellen Umsetzung (16 EiB konzeptbedingt)
Erlaubte Zeichen im Dateinamen alle Zeichen außer '\0' (NUL) und '/', Windows verbietet außerdem die folgenden Zeichen \ : * ? " < > |
Eigenschaften
Datumsangaben einer Datei Erzeugung, Änderung, Metadaten-Änderung, letzter Zugriff
Datumsbereich 1. Januar 1601 bis 28. Mai 60056[1], praktisch weniger[2][3]
Zeitstempel-Auflösung 100 ns[4]
Forks unterstützt
Dateiattribute schreibgeschützt, versteckt, System-Datei, Archiv
Dateirechte-Verwaltung ACL
Transparente Komprimierung auf Dateiebene, LZ77 (ab Windows NT 3.51)
Transparente Verschlüsselung auf Dateiebene
DESX (ab Windows 2000),
Triple DES (ab Windows XP),
AES (ab Windows XP Service Pack 1, Windows Server 2003)
Unterstützende Betriebssysteme nativ:
alle auf Windows-NT-basierenden Windowsversionen
andere Betriebssysteme:
über Fremdtreiber (Linux, MS-DOS, Windows 9x, macOS),
Einschränkungen: siehe nachstehende Angaben

NTFS ist ein proprietäres Dateisystem von Microsoft für alle Betriebssysteme der Windows-NT-Reihe (ab 1993). Die Abkürzung steht für New Technology File System.

Im Vergleich zum bis in die Windows-9x-Reihe verwendeten Dateisystem FAT bietet NTFS unter anderem einen gezielten Zugriffsschutz auf Dateiebene sowie größere Datensicherheit durch Journaling. Ein weiterer Vorteil von NTFS ist, dass die Dateigröße nicht wie bei FAT auf 4 GiB beschränkt ist. Allerdings ist NTFS für den Datenaustausch nicht so weit verbreitet wie FAT oder dessen moderne Variante exFAT, die einige der Einschränkungen wie das 4-GiB-Limit bei der Dateigröße nicht mehr hat. Derart große Dateien werden beispielsweise beim Erstellen von DVD-Abbildern benötigt. Neben NTFS nutzt Microsoft für einige Einsatzzwecke in seinen Produkten auch das Dateisystem ReFS.

Als die Entwicklung von Windows NT, dem späteren Microsoft Windows NT 3.1 begann, war noch nicht klar, welches Dateisystem das zukünftige Betriebssystem benutzen würde. Zu diesem Zeitpunkt existierten das Dateisystem FAT16, welches von MS-DOS verwendet wurde, und HPFS, das Dateisystem von OS/2. Das Dateisystem FAT war zu diesem Zeitpunkt bereits weit verbreitet, aber nach Ansicht von David Cutler erfüllten sowohl FAT als auch das fortschrittlichere HPFS nicht die Voraussetzungen an Zuverlässigkeit, die er an ein Dateisystem stellte.[5] Das neue Dateisystem musste nach seiner Ansicht in der Lage sein, beschädigte Dateien automatisch wiederherzustellen. Zudem hatten beide Dateisysteme Beschränkungen in der maximalen Dateigröße und -anzahl, und es war zu erwarten, dass das neue Betriebssystem in Zukunft größere Datenmengen verwalten würde.[6] Die Entwicklung eines dritten Dateisystems drohte allerdings den Zeitplan des Betriebssystems zu gefährden.[5]

So begann zunächst die Spezifikationsphase des neuen Dateisystems. Unter FAT16 waren Dateinamen auf das 8.3-Format beschränkt. Diese Namen waren durch die erzwungene Kürze oft kryptisch und darüber hinaus schwer zu merken. HPFS unterstützte zwar Dateinamen, die bis zu 255 Zeichen lang sind, aber ältere DOS- oder Windows-Programme konnten solche Dateien nicht sehen. NTFS sollte dieses Problem lösen, indem jeder lange Dateiname automatisch eine Kurzform erhielt, durch welche die Datei auch von älteren Anwendungen bearbeitet werden konnte.[7]

Die Entwicklung des neuen Dateisystems stand jedoch auf wackeligen Beinen. Der April 1991 hätte beinahe das Aus für NTFS bedeutet, als sich mehrere Entwickler dafür aussprachen, die Entwicklung dieses Dateisystems aus Zeitgründen zu beenden. Erst als Cutler, der sich zu dieser Zeit im Urlaub befand, zurückkehrte und die Wiederaufnahme der Entwicklung anordnete, gingen die Arbeiten weiter.[8] Im Februar 1992 begann die Testphase des neuen Dateisystems.[9] Erst im Oktober 1992 war das Dateisystem stabil genug für eine Implementierung.[10]

NTFS erbte viele Konzepte des Dateisystems HPFS von IBM, das in dem anfangs zusammen mit Microsoft entwickelten Betriebssystem OS/2 verwendet wurde, geht aber in einigen Aspekten weit darüber hinaus.

Im Gegensatz zu Inode-basierten Dateisystemen, welche bei Unix zum Einsatz kommen (Konzept: alles ist eine Datei), werden bei NTFS alle Informationen zu Dateien in einer Datei (Konzept: alles ist in einer Datei), der Master File Table, kurz MFT gespeichert. In dieser Datei befinden sich die Einträge, welche Blöcke zu welcher Datei gehören, die Zugriffsberechtigungen und die Attribute. Zu den Eigenschaften (Attributen) einer Datei gehören unter NTFS Dateigröße, Datum der Dateierstellung, Datum der letzten Änderung, Freigabe, Dateityp und auch der eigentliche Dateiinhalt.

Sehr kleine Dateien und Verzeichnisse werden in der MFT direkt abgespeichert. Größere Dateien werden dann als Attribut in einem Datenlauf gespeichert. Es existieren 4 Stadien des Dateiwachstums.[11]

Beim Formatieren der Festplatte wird für die MFT ein fester Platz reserviert, der nicht von anderen Dateien belegt werden kann. Wenn dieser Bereich mit Informationen komplett gefüllt ist, beginnt das Dateisystem freien Speicher vom Datenträger zu benutzen, wodurch es zu einer Fragmentierung der MFT kommen kann. Standardmäßig wird ein Bereich von 12,5 % der Partitionsgröße für die MFT reserviert.

Beim Speichern von Metadaten wird ein Journal geführt, was bedeutet, dass eine geplante Aktion zuerst in das Journal geschrieben wird. Erst dann wird der eigentliche Schreibzugriff auf die Daten ausgeführt, und abschließend wird das Journal aktualisiert. Wenn ein Schreibzugriff nicht vollständig beendet wird, zum Beispiel wegen eines Absturzes, braucht das Dateisystem nur die Änderungen im Journal zurückzunehmen und befindet sich anschließend wieder in einem konsistenten Zustand.

Die folgende Liste spiegelt die Zuordnung zwischen NTFS- und Windows-Version wider:

Versionskompatibilität

[Bearbeiten | Quelltext bearbeiten]
  • Einzige Aufwärtskompatibilität besteht für Version 3.0 zu 3.1, da die Datenträgerformate identisch sind. Somit kann selbst Windows NT 4.0 noch auf Windows-XP-Partitionen zugreifen, mit Ausnahme des für Windows-Domänencontroller nötigen USN-Journals bei einem Dualbootszenario auf demselben Rechner.[13] Windows NT 3.1 lässt sich mithilfe aktualisierter Systemdateien aus Windows NT 3.5 aktualisieren (NTFS 1.0 zu Version 1.1), wofür Microsoft eine offizielle Anleitung veröffentlicht hat.[12]
  • Grundsätzlich sind alle übrigen Versionen von NTFS zu früheren Versionen abwärtskompatibel (spätere Windows-Versionen haben Vollzugriff auf ältere NTFS-Versionen), aber zu späteren Versionen sind sie ohne aktualisierten Treiber nicht aufwärtskompatibel.

Unterschiede gegenüber dem Dateisystem FAT

[Bearbeiten | Quelltext bearbeiten]

Die Unterschiede gegenüber FAT sind:

  • effiziente Speichernutzung bei Partitionen über 400 MiB
  • Metadaten-Journaling: die Dateisystemstrukturen befinden sich immer in einem konsistenten Zustand
  • lange Dateinamen: Dateinamen können im Gegensatz zu FAT16 auch nativ (ohne VFAT) bis zu 255 Zeichen lang sein und aus fast beliebigen Unicode-Zeichen bestehen. NTFS unterscheidet zwischen Groß- und Kleinschreibung; dies wird zwar von Win32-Anwendungen nicht unterstützt, POSIX-Anwendungen können aber auch Dateien, die sich ausschließlich in der Groß- und Kleinschreibung unterscheiden, korrekt verwalten.[14]
  • eine maximale Länge des kompletten Pfadnamens von 32.767 Zeichen (allerdings beschränkt Windows bis zur Version Windows 10 Build 14352 die nutzbare Länge auf 260 Zeichen)
  • flexible Rechteverwaltung durch Verwendung von Access Control Lists
  • maximale Dateigröße von theoretisch 16 Exbibyte (EiB)
  • schnelle und effiziente Speicherung von kleinen Dateien direkt in der MFT (ab Windows NT 3.51 werden standardmäßig 4096 Byte große Cluster verwendet)
  • Speicherung von alternativen Datenströmen
  • transparente Komprimierung von Dateien (wird, obwohl von Beginn an entwickelt, erst ab der Version Windows NT 3.51 implementiert und nur bei unverschlüsselten Dateien und Clustergrößen bis 4 KiB unterstützt).
  • Datenverschlüsselung (nur auf Dateiebene)
  • Transparente Dateiverschlüsselung mit EFS (nicht in der Windows XP Home Edition und nur bei unkomprimierten Daten)
  • Kontingente, um den verwendbaren Festplattenplatz für einzelne Nutzer zu beschränken,
  • Analysepunkte (englisch Reparse Point) zur Verknüpfung von Aktionen/Funktionen mit Dateien oder Verzeichnissen,
  • Harte Links: Jede Datei kann von bis zu 1023 Dateinamen referenziert werden (eine Datei, viele Namen),
  • für Dateien mit vielen Leerinhalten werden, wenn sie als Datei mit geringer Datendichte gekennzeichnet sind, nur tatsächlich geschriebene Abschnitte gespeichert.
  • Erhöhte Defragmentierungsgeschwindigkeit.[15]

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.

Erweiterungen seit Windows Vista

[Bearbeiten | Quelltext bearbeiten]

Transactional NTFS (TxF)

[Bearbeiten | Quelltext bearbeiten]

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[16] (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.[17]

Standard-Clustergrößen und Einschränkungen

[Bearbeiten | Quelltext bearbeiten]

Je nach Größe des Laufwerks werden folgende Standard-Clustergrößen vergeben:[18]

Betriebssystem NT 3.51 NT 4.0 alle ab Windows 2000
Laufwerksgröße Clustergröße Sektoren Clustergröße Sektoren Clustergröße Sektoren
7 Mebibyte bis 512 MiB 512 Bytes 1 4.096 Bytes 8 4.096 Bytes 8
512 Mebibyte bis 1 GiB 1.024 Bytes 2 4.096 Bytes 8 4.096 Bytes 8
1 Gibibyte bis 2 GiB 2.048 Bytes 4 4.096 Bytes 8 4.096 Bytes 8
2 Gibibyte bis 2 TiB 4.096 Bytes 8 4.096 Bytes 8 4.096 Bytes 8
2 Tebibyte bis 16 TiB nicht unterstützt (MBR) nicht unterstützt (MBR) 4.096 Bytes 8
16 Tebibyte bis 32 TiB nicht unterstützt (MBR) nicht unterstützt (MBR) 8.192 Bytes 16
32 Tebibyte bis 64 TiB nicht unterstützt (MBR) nicht unterstützt (MBR) 16.384 Bytes 32
64 Tebibyte bis 128 TiB nicht unterstützt (MBR) nicht unterstützt (MBR) 32.768 Bytes 64
128 Tebibyte bis 256 TiB nicht unterstützt (MBR) nicht unterstützt (MBR) 65.536 Bytes 128
mehr als 256 Tebibyte nicht unterstützt nicht unterstützt nicht unterstützt

„nicht unterstützt (MBR)“ = Der Master Boot Record unterstützt nur Laufwerke bis 2 Tebibyte, darüber hinaus wird die GUID Partition Table verwendet, welche erst ab Windows 2000 und von Computern mit Extensible Firmware Interface unterstützt wird.

Dateinamen
Dateinamen sind auf 255 UTF-16 Zeichen beschränkt. Bestimmte Namen sind reserviert und können nur im Root-Verzeichnis eines Laufwerkes vergeben werden. Diese sind: $MFT, $MFTMirr, $LogFile, $Volume, $AttrDef, . (Punkt), $Bitmap, $Boot, $BadClus, $Secure, $Upcase und $Extend.[19] Pfade sind auf rund 32.767 Zeichen (UTF-16) beschränkt,[20] mit einigen API-Funktionen jedoch auf nur 260 Zeichen.[21]
Lange und kompatible kurze Dateinamen
Wenn Dateien ihren langen Dateinamen verloren haben und auf Dateien mit langem Dateinamen, aber denselben 8.3-Kurznamen treffen, kann es zu – auf den ersten Blick nicht ersichtlichen – Namenskollisionen kommen. Dies kann auch auftreten, nachdem beide Dateien in einem anderen Verzeichnis vorher friedlich koexistierten, wo die LFN-Datei einen anderen Kurznamen hatte.
Maximale Laufwerksgrößen
Theoretisch ist die maximale Laufwerksgröße von NTFS 264−1 Cluster. In der Praxis wird sie aber vom Betriebssystem eingeschränkt. Unter Windows XP Professional liegt sie bei 232−1 Cluster, was beispielsweise bei Verwendung von 64 KiB pro Cluster einer maximalen Laufwerksgröße von 256 TiB minus 64 KiB entspricht (unter Verwendung der Standardclustergröße von 4 KiB läge das Maximum bei 16 TiB minus 4 KiB). Da aber der Master Boot Record (MBR) nur Partitionen bis 2 TiB (≈ 2,2 TB) zulässt, müssen für mehr als 2 TiB dynamische oder GPT-Volumes benutzt werden. Das Booten von so einem Volume benötigt bei Microsoft Windows ein System mit EFI und 64 Bit.[22][23]
Maximale Dateigröße
Die maximale Dateigröße unter NTFS liegt theoretisch bei 16 EiB (16 × 10246 = 264 Bytes) minus 1 KiB (18.446.744.073.709.550.592 Bytes). In der Praxis jedoch vom Betriebssystem eingeschränkt: unter Windows XP 16 TiB (244 Bytes) minus 64 KiB.[23]
Dateien pro Laufwerk
Theoretisch 4.294.967.295 Dateien (232−1), was der maximalen Cluster-Anzahl entspricht, jedoch weiteren Ausnahmen und Restriktionen unterliegt.[23]

Unterstützung durch andere Betriebssysteme

[Bearbeiten | Quelltext bearbeiten]

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.[24] Linux sowie einige BSD-Variante inklusive macOS unterstützten über User-Mode-Treiber NTFS-3G vollständigen Lese- und Schreibzugriff, Lesezugriff auf verschlüsselte Dateien und die Formatierung von Datenträgern in NTFS.[25] Mit Linux-Kernel-Version 5.15 fügte Paragon seinen Treiber in den Hauptzweig ein.[26] macOS kann ab Version 10.3 NTFS-Dateisysteme lesen, aber nicht schreiben. In Version 10.6 (Snow Leopard) wurde eine versteckte Schreibfunktionalität gefunden, die aber nicht offiziell freigegeben ist.[27]

  • Harald Bögeholz: Datenleger. Defragmentierprogramme für NTFS. (c’t 21/2005, S. 178)

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. ColinFinck: time-rs / time – Use case for ‚large-dates‘ feature flag #306. (GitHub-Diskussion) In: GitHub. 29. März 2022, abgerufen am 16. August 2024 (englisch): „…time for years up to the maximum 60056 supported by NtfsTime.“
  2. Learn / Windows / Apps / Win32 / API / Minwinbase.h: SYSTEMTIME-Struktur (minwinbase.h). Microsoft, 4. März 2024, abgerufen am 16. August 2024: „Das Jahr. Die gültigen Werte für dieses Element sind 1601 bis 30827.“
  3. Interpretation of NTFS Timestamps. In: Forensic Focus. Upstart Digital Media Ltd, 6. April 2013, abgerufen am 16. August 2024 (englisch): „The documentation of FileTimeToSystemTime(), as well as practical tests, indicate that the FILETIME value to be translated must be 0x7FFFFFFFFFFFFFFF or less. This corresponds to the time 30828-09-14 02:48:05.4775807.“
  4. vectorsoft.de: Neue Funktion FsiStamp(): Zeitstempel in Dateisystemen, 13. März 2012, abgerufen am 29. Januar 2021.
  5. a b G. Pascal Zachary: Showstopper! The breakneck race to create Windows NT and the next generation at Microsoft. E-Rights/E-Reads, New York 2009, ISBN 0-7592-8578-0, S. 129 f.
  6. Zachary, S. 133.
  7. Zachary, S. 146 f.
  8. Zachary, S. 148–150.
  9. Zachary, S. 218.
  10. Zachary, S. 239.
  11. kexugit: Archived MSDN and TechNet Blogs. Abgerufen am 8. Januar 2023 (amerikanisches Englisch).
  12. a b STOP 7B When Not Updating File Systems for Windows NT 3.1. support.microsoft.com, abgerufen am 16. November 2015
  13. a b c Neue Möglichkeiten und Features des Dateisystems NTFS 3.1 – Seite bei Microsoft Hilfe und Support; Stand: 1. Dezember 2007
  14. Microsoft Knowledge Base - Filenames are Case Sensitive on NTFS Volumes. Abgerufen am 15. März 2013.
  15. Dateisysteme im Vergleich – FAT32 vs. NTFS. In: Allround-PC.com, abgerufen am 15. November 2013.
  16. Dokumentation zum Kernel Transaction Manager (englisch)
  17. Alternatives to using Transactional NTFS. In: Microsoft.com. 5. Dezember 2013, abgerufen am 13. Januar 2014 (englisch): „Microsoft strongly recommends developers investigate utilizing the discussed alternatives (or in some cases, investigate other alternatives) rather than adopting an API platform which may not be available in future versions of Windows.“
  18. Default cluster size for NTFS, FAT, and exFAT. KB 140365 (Revision: 9.1). Microsoft, 12. Juli 2013, abgerufen am 16. März 2014 (englisch).
  19. Archiveddocs: How NTFS Works: Local File Systems. Abgerufen am 8. Januar 2023 (amerikanisches Englisch).
  20. alvinashcraft: Benennen von Dateien, Pfaden und Namespaces - Win32 apps. Abgerufen am 8. Januar 2023 (deutsch).
  21. [MS-VDS]: MAX_PATH. Abgerufen am 8. Januar 2023 (amerikanisches Englisch).
  22. Booting from GPT. Abgerufen am 8. Januar 2023.
  23. a b c Working with File Systems. Abgerufen am 8. Januar 2023 (amerikanisches Englisch).
  24. Ingo Pakalski: Freeware erlaubt vollen NTFS-Zugriff von DOS aus. In: golem.de. 13. Oktober 2004, abgerufen am 8. Januar 2023.
  25. Michael Diestelberg: Community stellt freien NTFS-Treiber für Linux fertig. In: winfuture.de. 21. Februar 2007, abgerufen am 8. Januar 2023.
  26. Sebastian Grüner: Linux-Kernel bekommt neuen NTFS-Treiber. In: golem.de. 6. September 2021, abgerufen am 8. Januar 2023.
  27. Alvares, Milind: Snow Leopard’s hidden NTFS read/write support. 2. Oktober 2009, archiviert vom Original am 30. März 2015; abgerufen am 30. Juli 2015.