Freigeben über

exFAT-Dateisystemspezifikation

1 Einführung

Das exFAT-Dateisystem ist der Nachfolger von FAT32 in der FAT-Familie von Dateisystemen. Diese Spezifikation beschreibt das ExFAT-Dateisystem und stellt alle informationen bereit, die für die Implementierung des exFAT-Dateisystems erforderlich sind.

1.1 Designziele

Das ExFAT-Dateisystem hat drei zentrale Designziele (siehe Liste unten).

  1. Die Einfachheit von FAT-basierten Dateisystemen beibehalten.

    Zwei der Stärken von FAT-basierten Dateisystemen sind ihre relative Einfachheit und Einfache Implementierung. Im Geiste seiner Vorgänger sollten Implementierungen exFAT relativ einfach und einfach zu implementieren finden.

  2. Sehr große Dateien und Speichergeräte aktivieren.

    Das exFAT-Dateisystem verwendet 64 Bit, um die Dateigröße zu beschreiben, wodurch Anwendungen ermöglicht werden, die von sehr großen Dateien abhängen. Das ExFAT-Dateisystem ermöglicht auch Clustern so groß wie 32 MB, wodurch sehr große Speichergeräte effektiv ermöglicht werden.

  3. Integration der Erweiterbarkeit für zukünftige Innovationen.

    Das exFAT-Dateisystem integriert die Erweiterbarkeit in sein Design, sodass das Dateisystem mit Innovationen im Speicher und Änderungen der Nutzung schritt halten kann.

1.2 Spezifische Terminologie

Im Rahmen dieser Spezifikation tragen bestimmte Begriffe (siehe Tabelle 1) eine besondere Bedeutung für den Entwurf und die Implementierung des ExFAT-Dateisystems.

Tabelle 1 Definition von Begriffen, die sehr spezifische Bedeutung

Ausdrucks- Definition
Sollen Diese Spezifikation verwendet den Begriff "soll", um ein obligatorisches Verhalten zu beschreiben.
Sollen In dieser Spezifikation wird der Begriff "should" verwendet, um ein Verhalten zu beschreiben, das es dringend empfiehlt, aber nicht obligatorisch macht.
Mai In dieser Spezifikation wird der Begriff "may" verwendet, um ein optionales Verhalten zu beschreiben.
Obligatorisch Dieser Begriff beschreibt ein Feld oder eine Struktur, das durch eine Implementierung geändert und wie diese Spezifikation beschrieben wird.This term describes a field or structure which an implementation shall modify and shall interpret as this specification describes.
Wahlfrei Dieser Begriff beschreibt ein Feld oder eine Struktur, das von einer Implementierung unterstützt werden kann oder nicht. Wenn eine Implementierung ein bestimmtes optionales Feld oder eine bestimmte Struktur unterstützt, muss sie das Feld oder die Struktur so ändern und interpretieren, wie diese Spezifikation beschreibt.
Undefiniert Dieser Begriff beschreibt Feld- oder Strukturinhalte, die eine Implementierung bei Bedarf ändern kann (d. h. eindeutig auf Null, wenn umgebende Felder oder Strukturen festgelegt werden) und darf nicht so interpretiert werden, dass sie eine bestimmte Bedeutung haben.
Reserviert

Dieser Begriff beschreibt Feld- oder Strukturinhalte, die implementierungen:

  1. Initialisieren sie auf Null und sollten nicht zu irgendeinem Zweck verwendet werden.

  2. Sollte nicht interpretiert werden, außer beim Berechnen von Prüfsummen

  3. Bleibt bei allen Vorgängen erhalten, die die umgebenden Felder oder Strukturen ändern

1.3 Volltext allgemeiner Akronyme

Diese Spezifikation verwendet Akronyme in der allgemeinen Verwendung in der Personal Computerindustrie (siehe Tabelle 2).

Tabelle 2 Volltext allgemeiner Akronyme

Akronym- Volltext-
ASCII American Standard Code for Information Interchange
BIOS Grundlegendes Eingabeausgabesystem
CPU Zentrale Verarbeitungseinheit
exFAT erweiterbare Dateizuordnungstabelle
FETT Dateizuordnungstabelle
FAT12 Dateizuordnungstabelle, 12-Bit-Clusterindizes
FAT16 Dateizuordnungstabelle, 16-Bit-Clusterindizes
FAT32 Dateizuordnungstabelle, 32-Bit-Clusterindizes
GPT GUID-Partitionstabelle
GUID Globally Unique Identifier (siehe Abschnitt 10.1)
INT Unterbrechen
MBR Master Boot Record
texFAT Transaktionssicher exFAT
UTC Koordinierte Weltzeit

1.4 Standardfeld- und Strukturqualifizierer

Felder und Strukturen in dieser Spezifikation weisen die folgenden Qualifizierer auf (siehe Liste unten), es sei denn, die Spezifikationshinweise sind anders.

  1. Nicht signiert

  2. Verwenden Sie die Dezimalnotation, um Werte zu beschreiben, sofern nicht anders angegeben; diese Spezifikation verwendet den Postfixbuchstaben "h", um hexadezimale Zahlen zu kennzeichnen und GUIDs in geschweifte geschweifte Klammern einzuschließen.

  3. Sind im kleinen endischen Format

  4. Kein Null-Endzeichen für Zeichenfolgen erforderlich

1.5 Windows CE und TexFAT

TexFAT ist eine Erweiterung von exFAT, die transaktionssichere operative Semantik über dem Basisdateisystem hinzufügt. TexFAT wird von Windows CE verwendet. TexFAT erfordert die Verwendung der beiden FATs und Zuordnungsbitmaps für die Verwendung in Transaktionen. Außerdem werden mehrere zusätzliche Strukturen definiert, einschließlich Abstandsdeskriptoren und Sicherheitsdeskriptoren.

2 Volumenstruktur

Ein Volume ist der Satz aller Dateisystemstrukturen und datenspeicher, die zum Speichern und Abrufen von Benutzerdaten erforderlich sind. Alle ExFAT-Volumes enthalten vier Bereiche (siehe Tabelle 3).

Tabelle 3 Volumestruktur

Unterbereichsnamen

Offset-

(Sektor)

Größe

(Sektoren)

 Kommentare
Hauptstartbereich
Hauptstartsektor 0 1 Diese Unterregion ist obligatorisch und Abschnitt 3.1 definiert deren Inhalt.
Hauptsektoren für den erweiterten Start 1 8 Diese Unterregion ist obligatorisch und Abschnitt 3.2) definiert ihren Inhalt.
Haupt-OEM-Parameter 9 1 Diese Unterregion ist obligatorisch und Abschnitt 3.3 definiert deren Inhalte.
Haupt reserviert 10 1 Diese Unterregion ist obligatorisch, und der Inhalt ist reserviert.
Hauptstartprüfsumme 11 1 Diese Unterregion ist obligatorisch und Abschnitt 3.4 definiert deren Inhalt.
Sicherungsstartbereich
Sicherungsstartsektor 12 1 Diese Unterregion ist obligatorisch und Abschnitt 3.1 definiert deren Inhalt.
Sichern erweiterter Startsektoren 13 8 Diese Unterregion ist obligatorisch und Abschnitt 3.2 definiert ihren Inhalt.
OEM-Sicherungsparameter 21 1 Diese Unterregion ist obligatorisch und Abschnitt 3.3 definiert deren Inhalte.
Reservierte Sicherung 22 1 Diese Unterregion ist obligatorisch, und der Inhalt ist reserviert.
Prüfsumme des Sicherungsstarts 23 1 Diese Unterregion ist obligatorisch und Abschnitt 3.4 definiert deren Inhalt.
FAT-Region
FAT-Ausrichtung 24 FatOffset – 24

Diese Unterregion ist obligatorisch, und der Inhalt ist ggf. nicht definiert.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide das FatOffset-Feld.
Erstes FETT FatOffset FatLength

Diese Unterregion ist obligatorisch und Abschnitt 4.1 definiert ihren Inhalt.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide die Felder "FatOffset" und "FatLength".
Zweites FETT FatOffset + FatLength FatLength * (NumberOfFats – 1)

Diese Unterregion ist obligatorisch, und Abschnitt 4.1 definiert, falls vorhanden.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide die Felder "FatOffset", "FatLength" und "NumberOfFats". Das Feld "NumberOfFats" darf nur werte 1 und 2 enthalten.
Datenbereich
Cluster-Heapausrichtung FatOffset + FatLength * NumberOfFats ClusterHeapOffset – (FatOffset + FatLength * NumberOfFats)

Diese Unterregion ist obligatorisch, und der Inhalt ist ggf. nicht definiert.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide die Felder "FatOffset", "FatLength", "NumberOfFats" und "ClusterHeapOffset". Die gültigen Werte des Felds "NumberOfFats" sind 1 und 2.
Cluster-Heap ClusterHeapOffset ClusterCount * 2SectorsPerClusterShift

Diese Unterregion ist obligatorisch und Abschnitt 5.1 definiert ihren Inhalt.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide die Felder "ClusterHeapOffset", "ClusterCount" und "SectorsPerClusterShift".
Übermäßiger Speicherplatz ClusterHeapOffset + ClusterCount * 2SectorsPerClusterShift VolumeLength – (ClusterHeapOffset + ClusterCount * 2SectorsPerClusterShift)

Diese Unterregion ist obligatorisch, und der Inhalt ist ggf. nicht definiert.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide die Felder "ClusterHeapOffset", "ClusterCount", "SectorsPerClusterShift" und "VolumeLength".

3 Haupt- und Sicherungsstartbereiche

Der Hauptstartbereich bietet alle erforderlichen Anweisungen zum Startband, identifizieren von Informationen und Dateisystemparametern, um eine Implementierung zu ermöglichen, folgendes auszuführen:

  1. Starten Sie ein Computersystem von einem ExFAT-Volume.
  2. Identifizieren Sie das Dateisystem auf dem Volume als exFAT.
  3. Ermitteln Sie den Speicherort der exFAT-Dateisystemstrukturen.

Der Sicherungsstartbereich ist eine Sicherung des Hauptstartbereichs. Sie unterstützt die Wiederherstellung des exFAT-Volumes, wenn sich der Hauptstartbereich in einem inkonsistenten Zustand befindet. Außer unter seltenen Umständen, z. B. beim Aktualisieren von Startbandanweisungen, sollten Implementierungen den Inhalt des Sicherungsstartbereichs nicht ändern.

3.1 Haupt- und Sicherungsstartsektor-Unterregionen

Der Hauptstartsektor enthält Code zum Starten von einem ExFAT-Volume und grundlegenden ExFAT-Parametern, die die Volumestruktur beschreiben (siehe Tabelle 4). BIOS-, MBR- oder andere Boot-Strapping-Agents können diesen Sektor untersuchen und alle darin enthaltenen Boot-Strapping-Anweisungen laden und ausführen.

Der Sicherungsstartsektor ist eine Sicherung des Hauptstartsektors und hat dieselbe Struktur (siehe Tabelle 4). Der Sicherungsstartsektor kann Wiederherstellungsvorgänge unterstützen; Implementierungen müssen jedoch den Inhalt der Felder "VolumeFlags" und "PercentInUse" als veraltet behandeln.

Vor der Verwendung des Inhalts des Haupt- oder Sicherungsstartsektors überprüfen Implementierungen ihre Inhalte, indem sie ihre jeweilige Startprüfsumme überprüfen und sicherstellen, dass alle Felder innerhalb ihres gültigen Wertebereichs liegen.

Während der anfängliche Formatvorgang den Inhalt des Haupt- und Sicherungsstartsektors initialisiert, können Implementierungen diese Sektoren aktualisieren (und bei Bedarf auch ihre jeweilige Startprüfsumme aktualisieren). Implementierungen können jedoch entweder die Felder "VolumeFlags" oder "PercentInUse" aktualisieren, ohne die jeweilige Startprüfsumme zu aktualisieren (die Prüfsumme schließt diese beiden Felder ausdrücklich aus).

Tabelle 4 Haupt- und Sicherungsstartsektorstruktur

Feldname

Offset-

(Byte)

Größe

(Bytes)

 Kommentare
JumpBoot 0 3 Dieses Feld ist obligatorisch und Abschnitt 3.1.1 definiert seinen Inhalt.
DateisystemName 3 8 Dieses Feld ist obligatorisch und Abschnitt 3.1.2 definiert seinen Inhalt.
MustBeZero 11 53 Dieses Feld ist obligatorisch und Abschnitt 3.1.3 definiert seinen Inhalt.
PartitionOffset 64 8 Dieses Feld ist obligatorisch und Abschnitt 3.1.4 definiert seinen Inhalt.
VolumeLength 72 8 Dieses Feld ist obligatorisch und Abschnitt 3.1.5 definiert seinen Inhalt.
FatOffset 80 4 Dieses Feld ist obligatorisch und Abschnitt 3.1.6 definiert seinen Inhalt.
FatLength 84 4 Dieses Feld ist obligatorisch und Abschnitt 3.1.7 definiert seinen Inhalt.
ClusterHeapOffset 88 4 Dieses Feld ist obligatorisch und Abschnitt 3.1.8 definiert seinen Inhalt.
ClusterCount 92 4 Dieses Feld ist obligatorisch und Abschnitt 3.1.9 definiert seinen Inhalt.
FirstClusterOfRootDirectory 96 4 Dieses Feld ist obligatorisch und Abschnitt 3.1.10 definiert seinen Inhalt.
VolumeSerialNumber 100 4 Dieses Feld ist obligatorisch und Abschnitt 3.1.11 definiert seinen Inhalt.
FileSystemRevision 104 2 Dieses Feld ist obligatorisch und Abschnitt 3.1.12 definiert seinen Inhalt.
VolumeFlags 106 2 Dieses Feld ist obligatorisch und Abschnitt 3.1.13 definiert seinen Inhalt.
BytesPerSectorShift 108 1 Dieses Feld ist obligatorisch und Abschnitt 3.1.14 definiert seinen Inhalt.
SektorenProClusterSchicht 109 1 Dieses Feld ist obligatorisch und Abschnitt 3.1.15 definiert seinen Inhalt.
NumberOfFats 110 1 Dieses Feld ist obligatorisch und Abschnitt 3.1.16 definiert seinen Inhalt.
DriveSelect 111 1 Dieses Feld ist obligatorisch und Abschnitt 3.1.17 definiert seinen Inhalt.
ProzentInBenutzung 112 1 Dieses Feld ist obligatorisch und Abschnitt 3.1.18 definiert seinen Inhalt.
Reserviert 113 7 Dieses Feld ist obligatorisch, und der Inhalt ist reserviert.
BootCode 120 390 Dieses Feld ist obligatorisch und Abschnitt 3.1.19 definiert seinen Inhalt.
BootSignature 510 2 Dieses Feld ist obligatorisch und Abschnitt 3.1.20 definiert seinen Inhalt.
ExcessSpace 512 2BytesPerSectorShift – 512

Dieses Feld ist obligatorisch, und der Inhalt ist ggf. nicht definiert.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide das BytePerSectorShift-Feld.

3.1.1 JumpBoot Field

Das Feld "JumpBoot" muss die Sprunganweisung für CPUs enthalten, die bei ausführung der CPU zum Ausführen der Startbandanweisungen im Feld "BootCode" üblich sind.

Der gültige Wert für dieses Feld ist (in Der Reihenfolge von Byte mit niedriger Reihenfolge bis hochgeordnetes Byte) EBh 76h 90h.

3.1.2 FileSystemName-Feld

Das Feld "FileSystemName" muss den Namen des Dateisystems auf dem Volume enthalten.

Der gültige Wert für dieses Feld ist in ASCII-Zeichen "EXFAT", das drei nachfolgende Leerzeichen enthält.

3.1.3 MustBeZero Field

Das Feld "MustBeZero" entspricht direkt dem Bytebereich, den der gepackte BIOS-Parameterblock auf FAT12/16/32-Volumes verbraucht.

Der gültige Wert für dieses Feld ist 0, was dazu beiträgt, dass FAT12/16/32-Implementierungen versehentlich ein ExFAT-Volume anbringen.

3.1.4 PartitionOffset-Feld

Das Feld PartitionOffset beschreibt den medienrelativen Sektoroffset der Partition, die das angegebene exFAT-Volume hosten. Dieses Feld unterstützt das Startband von der Lautstärke mit erweiterten INT 13h auf Persönlichen Computern.

Alle möglichen Werte für dieses Feld sind gültig; Der Wert 0 weist jedoch darauf hin, dass die Implementierungen dieses Felds ignorieren.

3.1.5 VolumeLength Field

Das Feld "VolumeLength" beschreibt die Größe des angegebenen ExFAT-Volumens in Sektoren.

Der gültige Wertebereich für dieses Feld lautet:

  • Mindestens 220/ 2BytesPerSectorShift, wodurch sichergestellt wird, dass das kleinste Volume nicht kleiner als 1 MB ist

  • Höchstens 264- 1 kann der größte Wert dieses Felds beschreiben.

    Wenn die Größe des Unterbereichs "Überraum" jedoch 0 ist, ist der größte Wert dieses Felds ClusterHeapOffset + (232- 11) *2SectorsPerClusterShift.

3.1.6 FatOffset-Feld

Das Feld "FatOffset" beschreibt den volumenrelativen Sektorversatz des ersten FAT. Mit diesem Feld können Implementierungen das erste FAT an die Merkmale des zugrunde liegenden Speichermediums ausrichten.

Der gültige Wertebereich für dieses Feld lautet:

  • Mindestens 24 Bereiche, die für die Bereiche "Main Boot" und "Backup Boot" verwendet werden
  • Am meisten ClusterHeapOffset - (FatLength * NumberOfFats), die für die Sektoren, die der Cluster-Heap verbraucht

3.1.7 FatLength Field

Das Feld "FatLength" beschreibt die Länge jeder FAT-Tabelle (das Volumen kann bis zu zwei FATs enthalten).

Der gültige Wertebereich für dieses Feld lautet:

  • Mindestens (ClusterCount + 2) * 22/ 2BytesPerSectorShiftauf die nächste ganze Zahl aufgerundet, wodurch sichergestellt wird, dass jedes FAT ausreichend Platz zum Beschreiben aller Cluster im Cluster-Heap hat.
  • Höchstens (ClusterHeapOffset - FatOffset) / NumberOfFats rundet auf die nächste ganze Zahl ab, wodurch sichergestellt wird, dass die FATs vor dem Cluster Heap vorhanden sind.

Dieses Feld kann einen Wert enthalten, der über seine untere Grenze liegt (wie oben beschrieben), um das zweite FAT (sofern vorhanden) auch an die Merkmale des zugrunde liegenden Speichermediums auszurichten. Der Inhalt des Leerraums, der überschreitet, was das FAT selbst erfordert, falls vorhanden, ist nicht definiert.

3.1.8 ClusterHeapOffset-Feld

Das Feld ClusterHeapOffset beschreibt den volumenrelativen Sektorversatz des Cluster-Heaps. Mit diesem Feld können Implementierungen den Cluster-Heap an die Merkmale des zugrunde liegenden Speichermediums ausrichten.

Der gültige Wertebereich für dieses Feld lautet:

  • Mindestens FatOffset + FatLength * NumberOfFats, um die Sektoren aller vorherigen Regionen zu berücksichtigen
  • Höchstens 232- 1 oder VolumeLength - (ClusterCount * 2SectorsPerClusterShift), je nachdem, welche Berechnung kleiner ist

3.1.9 ClusterCount-Feld

Das Feld "ClusterCount" muss die Anzahl der Cluster beschreiben, die der Cluster-Heap enthält.

Der gültige Wert für dieses Feld ist der geringere der folgenden Werte:

  • (VolumeLength - ClusterHeapOffset) / 2SectorsPerClusterShiftauf die nächste ganze Zahl abgerundet, die genau die Anzahl der Cluster ist, die zwischen dem Anfang des Cluster heap und dem Ende des Volumes passen können.
  • 232- 11, die maximale Anzahl von Clustern, die ein FAT beschreiben kann

Der Wert des ClusterCount-Feldes bestimmt die Mindestgröße eines FAT. Um extrem große FATs zu vermeiden, können Implementierungen die Anzahl der Cluster im Cluster-Heap steuern, indem sie die Clustergröße erhöhen (über das Feld "SectorsPerClusterShift"). Diese Spezifikation empfiehlt nicht mehr als 224- 2 Cluster im Cluster Heap. Implementierungen müssen jedoch volumes mit bis zu 232- 11 Clustern im Cluster Heap verarbeiten können.

3.1.10 FirstClusterOfRootDirectory-Feld

Das Feld "FirstClusterOfRootDirectory" enthält den Clusterindex des ersten Clusters des Stammverzeichnisses. Implementierungen sollten alle Anstrengungen unternehmen, um den ersten Cluster des Stammverzeichnisses im ersten nicht ungültigen Cluster nach den Clustern zu platzieren, die die Zuordnungsbitmap und die Up-Case-Tabelle nutzen.

Der gültige Wertebereich für dieses Feld lautet:

  • Mindestens 2, der Index des ersten Clusters im Cluster Heap
  • Höchstens ClusterCount + 1, der Index des letzten Clusters im Cluster Heap

3.1.11 VolumeSerialNumber-Feld

Das Feld "VolumeSerialNumber" muss eine eindeutige fortlaufende Zahl enthalten. Dadurch werden Implementierungen unterstützt, um zwischen verschiedenen exFAT-Volumes zu unterscheiden. Implementierungen sollten die fortlaufende Zahl generieren, indem das Datum und die Uhrzeit der Formatierung des exFAT-Volumes kombiniert werden. Der Mechanismus zum Kombinieren von Datum und Uhrzeit, um eine fortlaufende Zahl zu bilden, ist implementierungsspezifisch.

Alle möglichen Werte für dieses Feld sind gültig.

3.1.12 DateisystemRevision-Feld

Das Feld "FileSystemRevision" beschreibt die haupt- und geringfügigen Revisionsnummern der exFAT-Strukturen auf dem angegebenen Volume.

Das Byte mit hoher Reihenfolge ist die Hauptrevisionsnummer, und das Byte mit niedriger Reihenfolge ist die kleinere Revisionsnummer. Wenn beispielsweise das Byte mit hoher Reihenfolge den Wert 01h enthält und das Byte mit niedriger Reihenfolge den Wert 05h enthält, beschreibt das Feld "FileSystemRevision" die Revisionsnummer 1,05. Wenn das Byte mit hoher Reihenfolge den Wert 0Ah enthält und das Byte mit niedriger Reihenfolge den Wert 0Fh enthält, beschreibt das FileSystemRevision-Feld die Revisionsnummer 10,15.

Der gültige Wertebereich für dieses Feld lautet:

  • Mindestens 0 für das Byte mit niedriger Reihenfolge und 1 für das Byte mit hoher Reihenfolge
  • Höchstens 99 für das Byte mit niedriger Reihenfolge und 99 für das Byte mit hoher Reihenfolge

Die Revisionsnummer von exFAT, die diese Spezifikation beschreibt, ist 1,00. Implementierungen dieser Spezifikation sollten alle exFAT-Volumes mit der Hauptrevisionsnummer 1 bereitstellen und dürfen kein exFAT-Volume mit einer anderen größeren Revisionsnummer bereitstellen. Implementierungen berücksichtigen die kleinere Revisionsnummer und dürfen keine Vorgänge ausführen oder Dateisystemstrukturen erstellen, die nicht in der entsprechenden Spezifikation der jeweiligen Kleineren Revisionsnummer beschrieben sind.

3.1.13 VolumeFlags-Feld

Das Feld "VolumeFlags" enthält Kennzeichnungen, die den Status verschiedener Dateisystemstrukturen auf dem ExFAT-Volume angeben (siehe Tabelle 5).

Implementierungen dürfen dieses Feld nicht enthalten, wenn die jeweilige Prüfsumme des Hauptstarts oder des Sicherungsstartbereichs berechnet wird. Wenn sie auf den Sicherungsstartsektor verweisen, müssen Implementierungen dieses Feld als veraltet behandeln.

Tabelle 5 VolumeFlags Feldstruktur

Feldname

Offset-

(Bit)

Größe

(Bits)

 Kommentare
ActiveFat 0 1 Dieses Feld ist obligatorisch und Abschnitt 3.1.13.1 definiert seinen Inhalt.
VolumenFehlerhaft 1 1 Dieses Feld ist obligatorisch und Abschnitt 3.1.13.2 definiert seinen Inhalt.
Mediafehler 2 1 Dieses Feld ist obligatorisch und Abschnitt 3.1.13.3 definiert seinen Inhalt.
ClearToZero 3 1 Dieses Feld ist obligatorisch und Abschnitt 3.1.13.4 definiert seinen Inhalt.
Reserviert 4 12 Dieses Feld ist obligatorisch, und der Inhalt ist reserviert.
3.1.13.1 ActiveFat-Feld

Das Feld "ActiveFat" beschreibt, welche FAT- und Zuordnungsbitmap aktiv sind (und implementierungen müssen verwendet werden), wie folgt:

  • 0, was bedeutet, dass die Bitmap "First FAT" und "First Allocation" aktiv sind
  • 1, was bedeutet, dass die Zweite FAT- und zweite Zuordnungsbitmap aktiv sind und nur möglich ist, wenn das Feld "NumberOfFats" den Wert 2 enthält.

Implementierungen müssen die inaktive FAT- und Zuordnungsbitmap als veraltet betrachten. Nur texFAT-fähige Implementierungen müssen die aktiven FAT- und Zuordnungsbitmaps wechseln (siehe Abschnitt 7.1).

3.1.13.2 VolumeDirty-Feld

Das Feld "VolumeDirty" beschreibt, ob das Volumen schmutzig ist oder nicht, wie folgt:

  • 0, was bedeutet, dass sich das Volumen wahrscheinlich in einem konsistenten Zustand befindet.
  • 1, was bedeutet, dass sich das Volume wahrscheinlich in einem inkonsistenten Zustand befindet

Implementierungen sollten den Wert dieses Felds auf 1 festlegen, wenn auf Dateisystemmetadaten Inkonsistenzen stoßen, die nicht aufgelöst werden. Wenn beim Bereitstellen eines Volumes der Wert dieses Felds 1 ist, können nur Implementierungen, die Dateisystemmetadateninkonsistenzen auflösen, den Wert dieses Felds auf 0 löschen. Diese Implementierungen müssen nur den Wert dieses Felds auf 0 löschen, nachdem sichergestellt wurde, dass sich das Dateisystem in einem konsistenten Zustand befindet.

Wenn bei der Bereitstellung eines Volumes der Wert dieses Felds 0 ist, sollten Implementierungen dieses Felds vor dem Aktualisieren von Dateisystemmetadaten auf 1 festlegen und dieses Feld anschließend auf 0 löschen, ähnlich wie die empfohlene Schreib sortierung, die in Abschnitt 8.1beschrieben ist.

3.1.13.3 MediaFailure-Feld

Im Feld "MediaFailure" wird beschrieben, ob eine Implementierung Medienfehler festgestellt hat oder nicht, wie folgt:

  • 0, was bedeutet, dass die Hostmedien keine Fehler gemeldet haben oder bekannte Fehler bereits in der FAT als "schlechte" Cluster aufgezeichnet wurden
  • 1, was bedeutet, dass die Hostmedien Fehler gemeldet haben (d. h. fehlgeschlagene Lese- oder Schreibvorgänge)

Eine Implementierung sollte dieses Feld auf 1 festlegen, wenn:

  1. Der Hostmedienzugriff auf alle Regionen im Volume schlägt fehl.
  2. Die Implementierung verfügt über erschöpfte Zugriffsüberprüfungsalgorithmen, falls vorhanden

Wenn beim Anbringen eines Volumes der Wert dieses Felds 1 ist, können Implementierungen, die das gesamte Volume auf Medienfehler überprüfen und alle Fehler als "schlechte" Cluster im FAT (oder anderweitig beheben Medienfehler) den Wert dieses Felds auf 0 löschen.

3.1.13.4 Feld ClearToZero

Das Feld ClearToZero hat in dieser Spezifikation keine erhebliche Bedeutung.

Die gültigen Werte für dieses Feld sind:

  • 0, das keine besondere Bedeutung hat
  • 1, was bedeutet, dass die Implementierungen dieses Felds vor dem Ändern von Dateisystemstrukturen, Verzeichnissen oder Dateien auf 0 löschen müssen

3.1.14 BytesPerSectorShift Field

Das Feld BytesPerSectorShift beschreibt die Bytes pro Sektor, die als Protokoll2(N) ausgedrückt werden, wobei N die Anzahl der Bytes pro Sektor ist. Bei 512 Byte pro Sektor beträgt der Wert dieses Felds beispielsweise 9.

Der gültige Wertebereich für dieses Feld lautet:

  • Mindestens 9 (Sektorgröße von 512 Bytes), die für ein exFAT-Volumen möglich ist
  • Höchstens 12 (Sektorgröße von 4096 Byte), bei denen es sich um die Arbeitsspeicherseitengröße von CPUs handelt, die auf Persönlichen Computern üblich sind

3.1.15 SectorsPerClusterShift Field

Das Feld "SektorenPerClusterShift" beschreibt die Sektoren pro Cluster, die als Protokoll2(N) ausgedrückt werden, wobei N die Anzahl der Sektoren pro Cluster ist. Bei 8 Sektoren pro Cluster beträgt der Wert dieses Felds beispielsweise 3.

Der gültige Wertebereich für dieses Feld lautet:

  • Mindestens 0 (1 Sektor pro Cluster), das ist der kleinste mögliche Cluster
  • Höchstens 25 - BytesPerSectorShift, das zu einer Clustergröße von 32 MB ausgewertet wird

3.1.16 AnzahlDerFats Feld

Das Feld "NumberOfFats" beschreibt die Anzahl der FATs und Zuordnungsbitmaps, die das Volume enthält.

Der gültige Wertebereich für dieses Feld lautet:

  • 1, das angibt, dass das Volume nur die Bitmap "First FAT" und "First Allocation" enthält
  • 2, das angibt, dass das Volume die Bitmap "First FAT", "Second FAT", "First Allocation Bitmap" und "Second Allocation Bitmap" enthält; Dieser Wert ist nur für TexFAT-Volumes gültig.

3.1.17 DriveSelect-Feld

Das Feld "DriveSelect" muss die erweiterte INT 13h-Laufwerksnummer enthalten, die das Startband von diesem Volume unter Verwendung erweiterter INT 13h auf PCs unterstützt.

Alle möglichen Werte für dieses Feld sind gültig. Ähnliche Felder in früheren FAT-basierten Dateisystemen enthielten häufig den Wert 80h.

3.1.18 FeldProzentInVerwendung

Das Feld "PercentInUse" beschreibt den Prozentsatz der Cluster im Cluster-Heap, der zugeordnet ist.

Der gültige Wertebereich für dieses Feld lautet:

  • Zwischen 0 und 100 einschließlich, was der Prozentsatz der zugeordneten Cluster im Cluster heap ist, wird auf die nächste ganze Zahl aufgerundet.
  • Genau FFh, der den Prozentsatz der zugeordneten Cluster im Cluster-Heap angibt, ist nicht verfügbar.

Implementierungen ändern den Wert dieses Felds, um Änderungen der Zuordnung von Clustern im Cluster-Heap widerzuspiegeln oder in FFh zu ändern.

Implementierungen dürfen dieses Feld nicht enthalten, wenn die jeweilige Prüfsumme des Hauptstarts oder des Sicherungsstartbereichs berechnet wird. Wenn sie auf den Sicherungsstartsektor verweisen, müssen Implementierungen dieses Feld als veraltet behandeln.

3.1.19 BootCode Field

Das Feld "BootCode" muss Anweisungen zum Startband enthalten. Implementierungen können dieses Feld mit den CPU-Anweisungen füllen, die zum Starten eines Computersystems erforderlich sind. Implementierungen, die keine Anweisungen zum Startband bereitstellen, müssen jedes Byte in diesem Feld als Teil des Formatvorgangs auf F4h (die Haltanweisung für CPUs, die in Persönlichen Computern üblich sind) initialisieren.

3.1.20 BootSignature-Feld

Das Feld "BootSignature" beschreibt, ob es sich bei einem bestimmten Sektor um einen Boot-Sektor handelt oder nicht.

Der gültige Wert für dieses Feld ist AA55h. Alle anderen Werte in diesem Feld ungültig den jeweiligen Startsektor. Implementierungen sollten den Inhalt dieses Felds vor jedem anderen Feld im jeweiligen Boot-Sektor überprüfen.

3.2 Haupt- und Sicherungssektoren für erweiterte Startbereiche

Jeder Sektor der Hauptsektoren für den erweiterten Boot hat die gleiche Struktur; Jeder Sektor kann jedoch unterschiedliche Anweisungen zum Startband enthalten (siehe Tabelle 6). Boot-Strapping-Agents, wie z. B. die Anweisungen zum Starten des Hauptstartsektors, alternative BIOS-Implementierungen oder firmware eines eingebetteten Systems, können diese Sektoren laden und die darin enthaltenen Anweisungen ausführen.

Die Sektoren für den erweiterten Sicherungsstart sind eine Sicherung der Hauptsektoren für den erweiterten Start und haben dieselbe Struktur (siehe Tabelle 6).

Vor der Ausführung der Anweisungen des Haupt- oder Sicherungsbereichs für den erweiterten Start sollten Implementierungen ihre Inhalte überprüfen, indem sichergestellt wird, dass das Feld "ExtendedBootSignature" jedes Sektors seinen vorgeschriebenen Wert enthält.

Während der anfängliche Formatvorgang sowohl den Inhalt des Haupt- als auch des Sicherungs-Erweiterten Startsektors initialisiert, können Implementierungen diese Sektoren aktualisieren (und bei Bedarf auch ihre jeweilige Startprüfsumme aktualisieren).

Tabelle 6 erweiterte Bootsektorstruktur

Feldname

Offset-

(Byte)

Größe

(Bytes)

 Kommentare
ErweiterterStartcode 0 2BytesPerSectorShift – 4

Dieses Feld ist obligatorisch und Abschnitt 3.2.1 definiert seinen Inhalt.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide das BytePerSectorShift-Feld.
ExtendedBootSignature 2BytesPerSectorShift – 4 4

Dieses Feld ist obligatorisch und Abschnitt 3.2.2 definiert seinen Inhalt.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide das BytePerSectorShift-Feld.

3.2.1 ExtendedBootCode-Feld

Das Feld "ExtendedBootCode" muss Anweisungen zum Startband enthalten. Implementierungen können dieses Feld mit den CPU-Anweisungen füllen, die zum Starten eines Computersystems erforderlich sind. Implementierungen, die keine Anweisungen zum Startband bereitstellen, müssen jedes Byte in diesem Feld im Rahmen ihres Formatvorgangs auf 00h initialisieren.

3.2.2 ExtendedBootSignature Field

Das Feld "ExtendedBootSignature" beschreibt, ob es sich bei dem angegebenen Sektor um einen erweiterten Boot-Sektor handelt oder nicht.

Der gültige Wert für dieses Feld ist AA550000h. Jeder andere Wert in diesem Feld ungültigt den jeweiligen Main- oder Backup Extended Boot Sector. Implementierungen sollten den Inhalt dieses Felds vor jedem anderen Feld in seinem jeweiligen erweiterten Startsektor überprüfen.

3.3 Haupt- und Sicherungs-OEM-Parameter Unterregionen

Die Unterregion "Haupt-OEM-Parameter" enthält zehn Parameterstrukturen, die herstellerspezifische Informationen enthalten können (siehe Tabelle 7). Jede der zehn Parameterstrukturen wird von der Vorlage "Generische Parameter" abgeleitet (siehe Abschnitt 3.3.2). Hersteller können ihre eigenen benutzerdefinierten Parameterstrukturen von der Vorlage "Generische Parameter" ableiten. Diese Spezifikation definiert selbst zwei Parameterstrukturen: Null-Parameter (siehe Abschnitt 3.3.3) und Flash-Parameter (siehe Abschnitt 3.3.4).

Die Oem-Sicherungsparameter sind eine Sicherung der Haupt-OEM-Parameter und haben dieselbe Struktur (siehe Tabelle 7).

Vor der Verwendung der Inhalte der Haupt- oder Sicherungs-OEM-Parameter überprüfen Implementierungen ihre Inhalte, indem sie ihre jeweilige Startprüfsumme überprüfen.

Hersteller sollten die Haupt- und Sicherungs-OEM-Parameter mit ihren eigenen benutzerdefinierten Parameterstrukturen( falls vorhanden) und anderen Parameterstrukturen auffüllen. Nachfolgende Formatvorgänge behalten den Inhalt der Haupt- und Sicherungs-OEM-Parameter bei.

Implementierungen können die Haupt- und Sicherungs-OEM-Parameter nach Bedarf aktualisieren (und muss auch ihre jeweilige Startprüfsumme aktualisieren).

Tabelle 7 OEM-Parameterstruktur

Feldname

Offset-

(Byte)

Größe

(Bytes)

 Kommentare
Parameter[0] 0 48 Dieses Feld ist obligatorisch und Abschnitt 3.3.1 definiert seinen Inhalt.

.

.

.

.

.

.

.

.

.

.

.

.
Parameter[9] 432 48 Dieses Feld ist obligatorisch und Abschnitt 3.3.1 definiert seinen Inhalt.
Reserviert 480 2BytesPerSectorShift – 480

Dieses Feld ist obligatorisch, und der Inhalt ist reserviert.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide das BytePerSectorShift-Feld.

3.3.1 Parameter[0] ... Parameter[9]

Jedes Parameterfeld in diesem Array enthält eine Parameterstruktur, die von der Vorlage "Generische Parameter" abgeleitet ist (siehe Abschnitt 3.3.2). Das Feld "Nicht verwendete Parameter" muss wie eine Nullparameterstruktur (siehe Abschnitt 3.3.3) beschrieben werden.

3.3.2 Vorlage für generische Parameter

Die Vorlage "Generische Parameter" stellt die Basisdefinition einer Parameterstruktur bereit (siehe Tabelle 8). Alle Parameterstrukturen werden von dieser Vorlage abgeleitet. Die Unterstützung für diese Vorlage für generische Parameter ist obligatorisch.

Tabelle 8 Generische Parametervorlage

Feldname

Offset-

(Byte)

Größe

(Bytes)

 Kommentare
ParametersGuid 0 16 Dieses Feld ist obligatorisch und Abschnitt 3.3.2.1 definiert seinen Inhalt.
CustomDefined 16 32 Dieses Feld ist obligatorisch, und die Strukturen, die von dieser Vorlage abgeleitet werden, definieren ihren Inhalt.
3.3.2.1 ParametersGuid-Feld

Das Feld ParameterGuid beschreibt eine GUID, die das Layout des Rests der angegebenen Parameterstruktur bestimmt.

Alle möglichen Werte für dieses Feld sind gültig; Hersteller sollten jedoch ein GUID-generierendes Tool wie GuidGen.exeverwenden, um beim Ableiten von benutzerdefinierten Parameterstrukturen aus dieser Vorlage eine GUID auszuwählen.

3.3.3 Nullparameter

Die Struktur "Null-Parameter" wird von der Vorlage "Generische Parameter" abgeleitet (siehe Abschnitt 3.3.2) und muss ein nicht verwendetes Parameterfeld beschreiben (siehe Tabelle 9). Beim Erstellen oder Aktualisieren der OEM-Parameterstruktur müssen Implementierungen nicht verwendete Parameterfelder mit der Struktur Nullparameter auffüllen. Darüber hinaus sollten Implementierungen beim Erstellen oder Aktualisieren der OEM-Parameterstruktur null-Parameterstrukturen am Ende des Arrays konsolidieren, wodurch alle anderen Parameterstrukturen am Anfang der OEM-Parameterstruktur verbleiben.

Die Unterstützung für die Struktur der Nullparameter ist obligatorisch.

Tabelle 9 Null-Parameterstruktur

Feldname

Offset-

(Byte)

Größe

(Bytes)

 Kommentare
Parameter-GUID 0 16 Dieses Feld ist obligatorisch und Abschnitt 3.3.3.1 definiert seinen Inhalt.
Reserviert 16 32 Dieses Feld ist obligatorisch, und der Inhalt ist reserviert.
3.3.3.1 ParametersGuid-Feld

Das Feld "ParametersGuid" muss der definition entsprechen, die von der Vorlage "Generische Parameter" bereitgestellt wird (siehe Abschnitt 3.3.2.1).

Der gültige Wert für dieses Feld in der GUID-Schreibweise ist {00000000-0000-0000-0000-000000000000}.

3.3.4 Flash-Parameter

Die FlashParameter-Struktur wird von der Vorlage "Generische Parameter" abgeleitet (siehe Abschnitt 3.3.2) und enthält Parameter für Flashmedien (siehe Tabelle 10). Hersteller von Flash-basierten Speichergeräten können ein Parameterfeld (vorzugsweise das Feld Parameter[0] ) mit dieser Parameterstruktur auffüllen. Implementierungen können die Informationen in der Struktur "Flash-Parameter" verwenden, um Zugriffsvorgänge während Lese-/Schreibvorgänge und für die Ausrichtung von Dateisystemstrukturen während der Formatierung der Medien zu optimieren.

Die Unterstützung für die Struktur der Flash-Parameter ist optional.

Tabelle 10 Flash-Parameterstruktur

Feldname

Offset-

(Byte)

Größe

(Bytes)

 Kommentare
ParametersGuid 0 16 Dieses Feld ist obligatorisch und Abschnitt 3.3.4.1 definiert seinen Inhalt.
EraseBlockSize 16 4 Dieses Feld ist obligatorisch und Abschnitt 3.3.4.2 definiert seinen Inhalt.
Pagesize 20 4 Dieses Feld ist obligatorisch und Abschnitt 3.3.4.3 definiert seinen Inhalt.
SpareSectors 24 4 Dieses Feld ist obligatorisch und Abschnitt 3.3.4.4 definiert seinen Inhalt.
RandomAccessTime 28 4 Dieses Feld ist obligatorisch und Abschnitt 3.3.4.5 definiert seinen Inhalt.
ProgrammierZeit 32 4 Dieses Feld ist obligatorisch und Abschnitt 3.3.4.6 definiert seinen Inhalt.
ReadCycle 36 4 Dieses Feld ist obligatorisch und Abschnitt 3.3.4.7 definiert seinen Inhalt.
WriteCycle 40 4 Dieses Feld ist obligatorisch und Abschnitt 3.3.4.8 definiert seinen Inhalt.
Reserviert 44 4 Dieses Feld ist obligatorisch, und der Inhalt ist reserviert.

Alle möglichen Werte für alle Felder "Flash-Parameter" mit Ausnahme des Felds "ParametersGuid" sind gültig. Der Wert 0 gibt jedoch an, dass das Feld eigentlich bedeutungslos ist (Implementierungen müssen das angegebene Feld ignorieren).

3.3.4.1 ParametersGuid-Feld

Das Feld "ParametersGuid" muss der definition entsprechen, die in der Vorlage "Generische Parameter" angegeben ist (siehe Abschnitt 3.3.2.1).

Der gültige Wert für dieses Feld in der GUID-Notation lautet {0A0C7E46-3399-4021-90C8-FA6D389C4BA2}.

3.3.4.2 EraseBlockSize-Feld

Das Feld "EraseBlockSize" beschreibt die Größe des Radierblocks von Flashmedien in Bytes.

3.3.4.3 PageSize-Feld

Das Feld "PageSize" beschreibt die Größe in Byte der Seite des Flash-Mediums.

3.3.4.4 Ersatzsektoren-Feld

Das Feld "SpareSectors" beschreibt die Anzahl der Sektoren, die die Flashmedien für ihre internen Sparing-Vorgänge zur Verfügung stehen.

3.3.4.5 RandomAccessTime-Feld

Das Feld "RandomAccessTime" beschreibt die durchschnittliche Zufällige Zugriffszeit der Flashmedien in Nanosekunden.

3.3.4.6 Programmierungszeit-Feld

Im Feld "ProgrammingTime" wird die durchschnittliche Programmierzeit der Flashmedien in Nanosekunden beschrieben.

3.3.4.7 Lesezyklusfeld

Das Feld "ReadCycle" beschreibt die durchschnittliche Lesezeit der Flashmedien in Nanosekunden.

3.3.4.8 Schreibzyklusfeld

Das Feld "WriteCycle" beschreibt die durchschnittliche Schreibzykluszeit in Nanosekunden.

3.4 Haupt- und Sicherungsstartprüfsumme-Unterregionen

Die Haupt- und Sicherungsstartprüfsummen enthalten jeweils ein wiederholtes Muster der Vier-Byte-Prüfsumme des Inhalts aller anderen Unterbereiche in ihren jeweiligen Startbereichen. Die Prüfsummenberechnung enthält nicht die Felder "VolumeFlags" und "PercentInUse" in ihrem jeweiligen Startsektor (siehe Abbildung 1). Das wiederholte Muster der Vier-Byte-Prüfsumme füllt den jeweiligen Startprüfsummen-Unterbereich von Anfang bis Ende des Unterbereichs.

Vor der Verwendung des Inhalts einer der anderen Unterregionen in den Haupt- oder Sicherungsstartbereichen müssen Implementierungen ihre Inhalte überprüfen, indem die jeweilige Startprüfsumme überprüft wird.

Während der anfängliche Formatvorgang sowohl die Haupt- als auch die Sicherungsstartprüfsummen mit dem wiederholten Prüfsummenmuster auffüllt, aktualisieren Implementierungen diese Sektoren, wenn sich die Inhalte der anderen Sektoren in ihren jeweiligen Startregionen ändern.

Abbildung 1 Startprüfsummenberechnung

UInt32 BootChecksum
(
    UCHAR  * Sectors,        // points to an in-memory copy of the 11 sectors
    USHORT   BytesPerSector
)
{
    UInt32 NumberOfBytes = (UInt32)BytesPerSector * 11;
    UInt32 Checksum = 0;
    UInt32 Index;

    for (Index = 0; Index < NumberOfBytes; Index++)
    {
        if ((Index == 106) || (Index == 107) || (Index == 112))
        {
            continue;
        }
        Checksum = ((Checksum&1) ? 0x80000000 : 0) + (Checksum>>1) + (UInt32)Sectors[Index];
    }

    return Checksum;
}

4 Dateizuordnungstabellenbereich

Die Dateizuordnungstabelle (FILE Allocation Table, FAT)-Region kann bis zu zwei FATs enthalten, eine in der Ersten FAT-Unterregion und eine in der zweiten FAT-Unterregion. Das Feld "NumberOfFats" beschreibt, wie viele FATs diese Region enthält. Die gültigen Werte für das Feld "NumberOfFats" sind 1 und 2. Daher enthält die Erste FAT-Unterregion immer ein FAT. Wenn das Feld "NumberOfFats" zwei ist, enthält der zweite FAT-Teilbereich auch ein FAT.

Das Feld "ActiveFat" des Felds "VolumeFlags" beschreibt, welche FAT aktiv ist. Nur das Feld "VolumeFlags" im Hauptstartsektor ist aktuell. Die Durchführungen behandeln das FAT, das nicht als veraltet aktiv ist. Die Verwendung der inaktiven FAT und der Wechsel zwischen FATs ist implementierungsspezifisch.

4.1 Erste und zweite FAT-Teilregionen

Ein FAT muss Clusterketten im Cluster-Heap beschreiben (siehe Tabelle 11). Eine Clusterkette ist eine Reihe von Clustern, die Platz zum Aufzeichnen der Inhalte von Dateien, Verzeichnissen und anderen Dateisystemstrukturen bieten. Ein FAT stellt eine Clusterkette als eine singly-verknüpfte Liste von Clusterindizes dar. Mit Ausnahme der ersten beiden Einträge stellt jeder Eintrag in einem FAT genau einen Cluster dar.

Tabelle 11 Dateizuordnungstabellenstruktur

Feldname

Offset-

(Byte)

Größe

(Bytes)

 Kommentare
FatEntry[0] 0 4 Dieses Feld ist obligatorisch und Abschnitt 4.1.1 definiert seinen Inhalt.
FatEntry[1] 4 4 Dieses Feld ist obligatorisch und Abschnitt 4.1.2 definiert seinen Inhalt.
FatEntry[2] 8 4 Dieses Feld ist obligatorisch und Abschnitt 4.1.3 definiert seinen Inhalt.

.

.

.

.

.

.

.

.

.

.

.

.
FatEntry[ClusterCount+1] (ClusterCount + 1) * 4 4

Dieses Feld ist obligatorisch und Abschnitt 4.1.3 definiert seinen Inhalt.

ClusterCount + 1 kann FFFFFFF6h niemals überschreiten.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide das ClusterCount-Feld.
ExcessSpace (ClusterCount + 2) * 4 (FatLength * 2BytesPerSectorShift) – ((ClusterCount + 2) * 4)

Dieses Feld ist obligatorisch, und der Inhalt ist ggf. nicht definiert.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide die Felder "ClusterCount", "FatLength" und "BytesPerSectorShift".

4.1.1 FatEntry[0] Feld

Das Feld "FatEntry[0] " beschreibt den Medientyp im ersten Byte (das niedrigste Byte) und muss FFh in den verbleibenden drei Byte enthalten.

Der Medientyp (das erste Byte) sollte F8h sein.

4.1.2 FatEntry[1] Field

Das Feld FatEntry[1] ist nur aufgrund der historischen Rangfolge vorhanden und beschreibt nichts von Interesse.

Der gültige Wert für dieses Feld ist FFFFFFFFh. Die Implementierungen initialisieren dieses Feld mit seinem vorgeschriebenen Wert und sollten dieses Feld nicht für irgendeinen Zweck verwenden. Implementierungen sollten dieses Feld nicht interpretieren und ihre Inhalte über Vorgänge hinweg beibehalten, die die umgebenden Felder ändern.

4.1.3 FatEntry[2] ... FatEntry[ClusterCount+1] Felder

Jedes FatEntry-Feld in diesem Array muss einen Cluster im Cluster heap darstellen. FatEntry[2] stellt den ersten Cluster im Cluster-Heap und FatEntry[ClusterCount+1] für den letzten Cluster im Cluster Heap dar.

Der gültige Wertebereich für diese Felder lautet:

  • Zwischen 2 und ClusterCount + 1 einschließlich, was auf das nächste FatEntry in der angegebenen Clusterkette verweist; die angegebene FatEntry darf auf keinen FatEntry verweisen, der ihm in der gegebenen Clusterkette vorausgeht.
  • Genau FFFFFFF7h, das den entsprechenden Cluster von FatEntry als "schlecht" markiert
  • Genau FFFFFFFFh, das den entsprechenden Cluster des FatEntry als letzten Cluster einer Clusterkette kennzeichnet; Dies ist der einzige gültige Wert für den letzten FatEntry einer bestimmten Clusterkette.

5 Datenregion

Der Datenbereich enthält den Cluster-Heap, der verwalteten Speicherplatz für Dateisystemstrukturen, Verzeichnisse und Dateien bereitstellt.

5.1 Cluster-Heap-Unterregion

Die Struktur des Cluster heap ist sehr einfach (siehe Tabelle 12); Jede aufeinander folgende Reihe von Sektoren beschreibt einen Cluster, wie das Feld "SectorsPerClusterShift" definiert. Wichtig ist, dass der erste Cluster des Cluster Heap Index 2 hat, der direkt dem Index von FatEntry[2] entspricht.

In einem exFAT-Volume verwaltet eine Zuordnungsbitmap (siehe Abschnitt 7.1.5) den Datensatz des Zuordnungsstatus aller Cluster. Dies ist ein erheblicher Unterschied zu den Vorgängern von exFAT (FAT12, FAT16 und FAT32), in dem ein FAT einen Datensatz des Zuordnungszustands aller Cluster im Cluster Heap bewahrte.

Tabelle 12 Cluster-Heapstruktur

Feldname

Offset-

(Sektor)

Größe

(Sektoren)

 Kommentare
Cluster[2] ClusterHeapOffset 2SectorsPerClusterShift

Dieses Feld ist obligatorisch und Abschnitt 5.1.1 definiert seinen Inhalt.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide die Felder "ClusterHeapOffset" und "SectorsPerClusterShift".

.

.

.

.

.

.

.

.

.

.

.

.
Cluster[ClusterCount+1] ClusterHeapOffset + (ClusterCount – 1) * 2SectorsPerClusterShift 2SectorsPerClusterShift

Dieses Feld ist obligatorisch und Abschnitt 5.1.1 definiert seinen Inhalt.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide die Felder "ClusterCount", "ClusterHeapOffset" und "SectorsPerClusterShift".

5.1.1 Cluster[2] ... Cluster[ClusterCount+1] Felder

Jedes Clusterfeld in diesem Array ist eine Reihe zusammenhängender Sektoren, deren Größe durch das Feld "SectorsPerClusterShift" definiert wird.

6 Verzeichnisstruktur

Das exFAT-Dateisystem verwendet einen Verzeichnisstrukturansatz, um die Dateisystemstrukturen und Dateien zu verwalten, die im Cluster Heap vorhanden sind. Verzeichnisse weisen eine 1:n-Beziehung zwischen übergeordnetem und untergeordnetem Element in der Verzeichnisstruktur auf.

Das Verzeichnis, auf das sich das Feld "FirstClusterOfRootDirectory" bezieht, ist der Stamm der Verzeichnisstruktur. Alle anderen Verzeichnisse stammen aus dem Stammverzeichnis in einer singly verknüpften Weise.

Jedes Verzeichnis besteht aus einer Reihe von Verzeichniseinträgen (siehe Tabelle 13).

Mindestens ein Verzeichniseintragssatz wird in einem Verzeichniseintragssatz kombiniert, der etwas Interessantes beschreibt, z. B. eine Dateisystemstruktur, ein Unterverzeichnis oder eine Datei.

Tabelle 13 Verzeichnisstruktur

Feldname

Offset-

(Byte)

Größe

(Byte)

 Kommentare
DirectoryEntry[0] 0 32 Dieses Feld ist obligatorisch und Abschnitt 6.1 definiert seinen Inhalt.

.

.

.

.

.

.

.

.

.

.

.

.
Verzeichniseintrag[N–1] (N – 1) * 32 32

Dieses Feld ist obligatorisch und Abschnitt 6.1 definiert seinen Inhalt.

N, die Anzahl der DirectoryEntry-Felder, ist die Größe der Clusterkette in Bytes, die das angegebene Verzeichnis enthält, dividiert durch die Größe eines DirectoryEntry-Felds, 32 Byte.

6.1 DirectoryEntry[0] ... DirectoryEntry[N--1]

Jedes DirectoryEntry-Feld in diesem Array wird von der Generischen DirectoryEntry-Vorlage abgeleitet (siehe Abschnitt 6.2).

6.2 Generische DirectoryEntry-Vorlage

Die Generische DirectoryEntry-Vorlage stellt die Basisdefinition für Verzeichniseinträge bereit (siehe Tabelle 14). Alle Verzeichniseintragsstrukturen werden von dieser Vorlage abgeleitet, und nur von Microsoft definierte Verzeichniseintragsstrukturen sind gültig (exFAT enthält keine Bestimmungen für herstellerdefinierte Verzeichniseintragsstrukturen, außer gemäß Abschnitt 7.8 und Abschnitt 7.9). Die Möglichkeit, die Generische DirectoryEntry-Vorlage zu interpretieren, ist obligatorisch.

Tabelle 14 Generische DirectoryEntry-Vorlage

Feldname

Offset-

(Byte)

Größe

(Byte)

 Kommentare
Eintragstyp 0 1 Dieses Feld ist obligatorisch und Abschnitt 6.2.1 definiert seinen Inhalt.
CustomDefined 1 19 Dieses Feld ist obligatorisch und Strukturen, die von dieser Vorlage abgeleitet werden, können ihre Inhalte definieren.
FirstCluster 20 4 Dieses Feld ist obligatorisch und Abschnitt 6.2.2 definiert seinen Inhalt.
Datenlänge 24 8 Dieses Feld ist obligatorisch und Abschnitt 6.2.3 definiert seinen Inhalt.

6.2.1 EntryType Field

Das EntryType-Feld verfügt über drei Verwendungsmodi, die der Wert des Felds definiert (siehe Liste unten).

  • 00h, eine Verzeichnisendemarkierung, und die folgenden Bedingungen gelten:
    • Alle anderen Felder im angegebenen DirectoryEntry sind tatsächlich reserviert.
    • Alle nachfolgenden Verzeichniseinträge im angegebenen Verzeichnis sind auch End-of-Directory-Markierungen.
    • End-of-Directory-Markierungen sind nur außerhalb von Verzeichniseintragssätzen gültig.
    • Implementierungen können End-of-Directory-Markierungen bei Bedarf überschreiben.
  • Zwischen 01h und 7Fh einschließlich, was einen Marker für nicht verwendete Verzeichniseinträge darstellt und unter die folgenden Bedingungen fällt:
    • Alle anderen Felder im angegebenen DirectoryEntry sind tatsächlich nicht definiert.
    • Nicht verwendete Verzeichniseinträge sind nur außerhalb von Verzeichniseintragssätzen gültig.
    • Implementierungen können bei Bedarf nicht verwendete Verzeichniseinträge überschreiben.
    • Dieser Wertebereich entspricht dem Feld "InUse" (siehe Abschnitt 6.2.1.4), der den Wert 0 enthält.
  • Zwischen 81h und FFh einschließlich, wobei es sich um einen regulären Verzeichniseintrag handelt und folgende Bedingungen gelten:
    • Der Inhalt des EntryType-Felds (siehe Tabelle 15) bestimmen das Layout des Restlichen der DirectoryEntry-Struktur.
    • Dieser Wertebereich und nur dieser Wertebereich sind innerhalb eines Verzeichniseintragssatzes gültig.
    • Dieser Wertebereich entspricht direkt dem Feld "InUse" (siehe Abschnitt 6.2.1.4), der den Wert 1 enthält.

Um Änderungen am InUse-Feld zu verhindern (siehe Abschnitt 6.2.1.4), was zu einer End-of-Directory-Markierung führt, ist der Wert 80h ungültig.

Tabelle 15 Generische EntryType-Feldstruktur

Feldname

Offset-

(Bit)

Größe

(Bits)

 Kommentare
TypeCode 0 5 Dieses Feld ist obligatorisch und Abschnitt 6.2.1.1 definiert seinen Inhalt.
Typenbedeutung 5 1 Dieses Feld ist obligatorisch und Section Section 6.2.1.2 definiert seinen Inhalt.
TypeCategory (Typ) 6 1 Dieses Feld ist obligatorisch und Abschnitt 6.2.1.3 definiert seinen Inhalt.
InUse 7 1 Dieses Feld ist obligatorisch und Abschnitt 6.2.1.4 definiert seinen Inhalt.
6.2.1.1 TypeCode-Feld

Das TypeCode-Feld beschreibt teilweise den spezifischen Typ des angegebenen Verzeichniseintrags. Dieses Feld sowie die Felder "TypeImportance" und "TypeCategory" (siehe Abschnitt 6.2.1.2 und Abschnitt 6.2.1.3) identifizieren den Typ des angegebenen Verzeichniseintrags eindeutig.

Alle möglichen Werte dieses Felds sind gültig, es sei denn, die Felder 'TypeImportance' und 'TypeCategory' enthalten beide den Wert 0; in diesem Fall ist der Wert 0 für dieses Feld ungültig.

6.2.1.2 TypeImportance-Feld

Das Feld "TypeImportance" beschreibt die Bedeutung des angegebenen Verzeichniseintrags.

Die gültigen Werte für dieses Feld sind:

  • 0, was bedeutet, dass der angegebene Verzeichniseintrag kritisch ist (siehe Abschnitt 6.3.1.2.1 und Abschnitt 6.4.1.2.1 für kritische primär- und kritische sekundäre Verzeichniseinträge).
  • 1, was bedeutet, dass der angegebene Verzeichniseintrag gutartig ist (siehe Abschnitt 6.3.1.2.2 bzw. Abschnitt 6.4.1.2.2 für gutartige primär- und gutartige sekundäre Verzeichniseinträge).
6.2.1.3 TypeCategory Field

Das Feld "TypeCategory" beschreibt die Kategorie des angegebenen Verzeichniseintrags.

Die gültigen Werte für dieses Feld sind:

  • 0, was bedeutet, dass der angegebene Verzeichniseintrag primär ist (siehe Abschnitt 6.3)
  • 1, was bedeutet, dass der angegebene Verzeichniseintrag sekundär ist (siehe Abschnitt 6.4)
6.2.1.4 InUse-Feld

Im Feld "InUse" wird beschrieben, ob der angegebene Verzeichniseintrag verwendet wird oder nicht.

Die gültigen Werte für dieses Feld sind:

  • 0, was bedeutet, dass der angegebene Verzeichniseintrag nicht verwendet wird; dies bedeutet, dass die angegebene Struktur tatsächlich ein nicht verwendeter Verzeichniseintrag ist.
  • 1, was bedeutet, dass der angegebene Verzeichniseintrag verwendet wird; dies bedeutet, dass die angegebene Struktur ein regulärer Verzeichniseintrag ist.

6.2.2 FirstCluster Field

Das Feld "FirstCluster" enthält den Index des ersten Clusters einer Zuordnung im Cluster heap, der dem angegebenen Verzeichniseintrag zugeordnet ist.

Der gültige Wertebereich für dieses Feld lautet:

  • Genau 0, was bedeutet, dass keine Clusterzuordnung vorhanden ist
  • Zwischen 2 und ClusterCount + 1, also dem Bereich gültiger Clusterindizes

Strukturen, die von dieser Vorlage abgeleitet werden, können sowohl die Felder "FirstCluster" als auch "DataLength" neu definieren, wenn eine Clusterzuordnung nicht mit der abgeleiteten Struktur kompatibel ist.

6.2.3 DataLength-Feld

Das Feld "DataLength" beschreibt die Größe der Daten in Bytes, die die zugeordnete Clusterzuordnung enthält.

Der gültige Wertebereich für dieses Feld lautet:

  • Mindestens 0; wenn das Feld "FirstCluster" den Wert 0 enthält, ist der einzige gültige Wert dieses Felds 0.
  • Höchstens ClusterCount * 2SectorsPerClusterShift* 2BytesPerSectorShift

Strukturen, die von dieser Vorlage abgeleitet werden, können sowohl die Felder "FirstCluster" als auch "DataLength" neu definieren, wenn eine Clusterzuordnung für die abgeleitete Struktur nicht möglich ist.

6.3 Generische Primäre Verzeichnisentry-Vorlage

Der erste Verzeichniseintrag in einem Verzeichniseintragssatz ist ein Primärverzeichniseintrag. Alle nachfolgenden Verzeichniseinträge sind gegebenenfalls im Verzeichniseintragssatz sekundäre Verzeichniseinträge (siehe Abschnitt 6.4).

Die Möglichkeit zum Interpretieren der vorlage "Generic Primary DirectoryEntry" ist obligatorisch.

Alle primären Verzeichniseintragsstrukturen werden von der Vorlage "Generic Primary DirectoryEntry" abgeleitet (siehe Tabelle 16), die von der Vorlage "Generic DirectoryEntry" abgeleitet ist (siehe Abschnitt 6.2).

Tabelle 16 generische Primäre Verzeichnisentry-Vorlage

Feldname

Offset-

(Byte)

Größe

(Byte)

 Kommentare
Eintragstyp 0 1 Dieses Feld ist obligatorisch und Abschnitt 6.3.1 definiert seinen Inhalt.
Sekundäranzahl 1 1 Dieses Feld ist obligatorisch und Abschnitt 6.3.2 definiert seinen Inhalt.
SetChecksum 2 2 Dieses Feld ist obligatorisch und Abschnitt 6.3.3 definiert seinen Inhalt.
AllgemeinePrimärFlags 4 2 Dieses Feld ist obligatorisch und Abschnitt 6.3.4 definiert seinen Inhalt.
CustomDefined 6 14 Dieses Feld ist obligatorisch und Strukturen, die von dieser Vorlage abgeleitet sind, definieren ihren Inhalt.
FirstCluster 20 4 Dieses Feld ist obligatorisch und Abschnitt 6.3.5 definiert seinen Inhalt.
Datenlänge 24 8 Dieses Feld ist obligatorisch und Abschnitt 6.3.6 definiert seinen Inhalt.

6.3.1 Eintragstyp-Feld

Das Feld "EntryType" muss der definition entsprechen, die in der Vorlage "Generic DirectoryEntry" angegeben ist (siehe Abschnitt 6.2.1).

6.3.1.1 TypeCode-Feld

Das Feld "TypeCode" muss der definition entsprechen, die in der Vorlage "Generic DirectoryEntry" angegeben ist (siehe Abschnitt 6.2.1.1).

6.3.1.2 TypeImportance-Feld

Das Feld "TypeImportance" entspricht der Definition in der Vorlage "Generic DirectoryEntry" (siehe Abschnitt 6.2.1.2).

6.3.1.2.1 Kritische Primärverzeichniseinträge

Kritische Primärverzeichniseinträge enthalten Informationen, die für die ordnungsgemäße Verwaltung eines exFAT-Volumes von entscheidender Bedeutung sind. Nur das Stammverzeichnis enthält wichtige primäre Verzeichniseinträge (Dateiverzeichniseinträge sind eine Ausnahme, siehe Abschnitt 7.4).

Die Definition kritischer Primärverzeichniseinträge korreliert mit der wichtigsten exFAT-Revisionsnummer. Implementierungen unterstützen alle kritischen Primärverzeichniseinträge und erfassen nur die kritischen Primärverzeichniseintragsstrukturen, die diese Spezifikation definiert.

6.3.1.2.2 Gutartige Primärverzeichniseinträge

Gutartige Primärverzeichniseinträge enthalten zusätzliche Informationen, die für die Verwaltung eines exFAT-Volumes nützlich sein können. Jedes Verzeichnis kann gutartige primäre Verzeichniseinträge enthalten.

Die Definition gutartiger Primärverzeichniseinträge korreliert mit der geringfügigen exFAT-Revisionsnummer. Die Unterstützung für jeden gutartigen primären Verzeichniseintrag dieser Spezifikation oder einer nachfolgenden Spezifikation ist optional. Ein nicht erkannter gutartiger primärer Verzeichniseintrag rendert den gesamten Verzeichniseintrag als nicht erkannt (über die Definition der anwendbaren Verzeichniseintragsvorlagen hinaus).

6.3.1.3 TypKategorie-Feld

Das Feld "TypeCategory" entspricht der Definition in der Vorlage "Generic DirectoryEntry" (siehe Abschnitt 6.2.1.3).

Für diese Vorlage muss der gültige Wert für dieses Feld 0 sein.

6.3.1.4 InUse-Feld

Das Feld "InUse" entspricht der Definition in der Vorlage "Generic DirectoryEntry" (siehe Abschnitt 6.2.1.4).

6.3.2 SecondaryCount-Feld

Das Feld "SecondaryCount" beschreibt die Anzahl der sekundären Verzeichniseinträge, die unmittelbar auf den angegebenen Primärverzeichniseintrag folgen. Diese sekundären Verzeichniseinträge zusammen mit dem angegebenen primären Verzeichniseintrag umfassen den Verzeichniseintragssatz.

Der gültige Wertebereich für dieses Feld lautet:

  • Mindestens 0, was bedeutet, dass dieser primäre Verzeichniseintrag der einzige Eintrag im Verzeichniseintragssatz ist.
  • Höchstens 255, was bedeutet, dass die nächsten 255 Verzeichniseinträge und dieser Primärverzeichniseintrag den Verzeichniseintragssatz umfasst.

Kritische Primärverzeichniseintragsstrukturen, die von dieser Vorlage abgeleitet werden, können sowohl die Felder SecondaryCount als auch SetChecksum neu definieren.

6.3.3 SetChecksum Field

Das Feld "SetChecksum" enthält die Prüfsumme aller Verzeichniseinträge im angegebenen Verzeichniseintragssatz. Die Prüfsumme schließt dieses Feld jedoch aus (siehe Abbildung 2). Die Implementierungen überprüfen, ob der Inhalt dieses Felds gültig ist, bevor ein anderer Verzeichniseintrag im angegebenen Verzeichniseintragssatz verwendet wird.

Kritische Primärverzeichniseintragsstrukturen, die von dieser Vorlage abgeleitet werden, können sowohl die Felder SecondaryCount als auch SetChecksum neu definieren.

Abbildung 2 EntrySetChecksum-Berechnung

UInt16 EntrySetChecksum
(
    UCHAR * Entries,       // points to an in-memory copy of the directory entry set
    UCHAR   SecondaryCount
)
{
    UInt16 NumberOfBytes = ((UInt16)SecondaryCount + 1) * 32;
    UInt16 Checksum = 0;
    UInt16 Index;

    for (Index = 0; Index < NumberOfBytes; Index++)
    {
        if ((Index == 2) || (Index == 3))
        {
            continue;
        }
        Checksum = ((Checksum&1) ? 0x8000 : 0) + (Checksum>>1) +  (UInt16)Entries[Index];
    }
    return Checksum;
}

6.3.4 GeneralPrimaryFlags Field

Das Feld "GeneralPrimaryFlags" enthält Flags (siehe Tabelle 17).

Kritische Primärverzeichniseintragsstrukturen, die von dieser Vorlage abgeleitet werden, können dieses Feld neu definieren.

Tabelle 17 Allgemeine GeneralPrimaryFlags-Feldstruktur

Feldname

Offset-

(Bit)

Größe

(Bits)

 Kommentare
ZuweisungMöglich 0 1 Dieses Feld ist obligatorisch und Abschnitt 6.3.4.1 definiert seinen Inhalt.
NoFatChain 1 1 Dieses Feld ist obligatorisch und Abschnitt 6.3.4.2 definiert seinen Inhalt.
CustomDefined 2 14 Dieses Feld ist obligatorisch und Strukturen, die von dieser Vorlage abgeleitet werden, können dieses Feld definieren.
6.3.4.1 AllocationPossible Field

Das Feld "AllocationPossible" muss beschreiben, ob für den angegebenen Verzeichniseintrag eine Zuordnung im Cluster heap möglich ist.

Die gültigen Werte für dieses Feld sind:

  • 0, was bedeutet, dass eine zugeordnete Zuordnung von Clustern nicht möglich ist und die Felder "FirstCluster" und "DataLength" tatsächlich nicht definiert sind (Strukturen, die von dieser Vorlage abgeleitet werden, können diese Felder neu definieren)
  • 1, was bedeutet, dass eine zugeordnete Zuordnung von Clustern möglich ist und die Felder "FirstCluster" und "DataLength" wie definiert sind
6.3.4.2 NoFatChain Field

Das Feld "NoFatChain" gibt an, ob das aktive FAT die Clusterkette der angegebenen Zuordnung beschreibt.

Die gültigen Werte für dieses Feld sind:

  • 0, was bedeutet, dass die entsprechenden FAT-Einträge für die Clusterkette der Zuordnung gültig sind und die Umsetzungen sie interpretieren; wenn das Feld "AllocationPossible" den Wert 0 enthält oder wenn das Feld "AllocationPossible" den Wert 1 enthält und das Feld "FirstCluster" den Wert 0 enthält, ist der einzige gültige Wert dieses Felds 0.
  • 1, was bedeutet, dass die zugeordnete Zuweisung eine zusammenhängende Reihe von Clustern ist; die entsprechenden FAT-Einträge für die Cluster sind ungültig, und die Umsetzungen dürfen sie nicht interpretieren; Implementierungen können die folgende Gleichung verwenden, um die Größe der zugeordneten Zuordnung zu berechnen: DataLength / (2SectorsPerClusterShift* 2BytesPerSectorShift) aufgerundet auf die nächste ganze Zahl

Wenn kritische Primärverzeichniseingabestrukturen, die von dieser Vorlage abgeleitet werden, das Feld "GeneralPrimaryFlags" neu definieren, sind die entsprechenden FAT-Einträge für die Clusterkette der zugeordneten Zuordnung gültig.

6.3.5 FirstCluster Field

Das Feld "FirstCluster" muss der definition entsprechen, die in der Vorlage "Generic DirectoryEntry" angegeben ist (siehe Abschnitt 6.2.2).

Wenn das NoFatChain-Bit 1 ist, muss FirstCluster auf einen gültigen Cluster im Cluster heap zeigen.

Kritische Primärverzeichniseintragsstrukturen, die von dieser Vorlage abgeleitet werden, können die Felder "FirstCluster" und "DataLength" neu definieren. Andere Strukturen, die von dieser Vorlage abgeleitet werden, können die Felder "FirstCluster" und "DataLength" nur neu definieren, wenn das Feld "AllocationPossible" den Wert 0 enthält.

6.3.6 Datenlängenfeld

Das Feld "DataLength" entspricht der definition, die in der Vorlage "Generic DirectoryEntry" angegeben ist (siehe Abschnitt 6.2.3).

Wenn das NoFatChain-Bit 1 ist, darf "DataLength" nicht null sein. Wenn das Feld "FirstCluster" null ist, muss "DataLength" ebenfalls null sein.

Kritische Primärverzeichniseintragsstrukturen, die von dieser Vorlage abgeleitet werden, können die Felder "FirstCluster" und "DataLength" neu definieren. Andere Strukturen, die von dieser Vorlage abgeleitet werden, können die Felder "FirstCluster" und "DataLength" nur neu definieren, wenn das Feld "AllocationPossible" den Wert 0 enthält.

6.4 Generische Vorlage für sekundäre Verzeichnisse

Der zentrale Zweck sekundärer Verzeichniseinträge besteht darin, zusätzliche Informationen zu einem Verzeichniseintragssatz bereitzustellen. Die Möglichkeit, die Generische SekundärverzeichnisEntry-Vorlage zu interpretieren, ist obligatorisch.

Die Definition von kritischen und gutartigen sekundären Verzeichniseinträgen korreliert mit der geringfügigen exFAT-Revisionsnummer. Unterstützung für kritische oder gutartige sekundäre Verzeichniseinträge, die diese Spezifikation oder nachfolgende Spezifikationen definieren, ist optional.

Alle sekundären Verzeichniseintragsstrukturen werden von der Vorlage "Generic Secondary DirectoryEntry" abgeleitet (siehe Tabelle 18), die von der Vorlage "Generic DirectoryEntry" abgeleitet ist (siehe Abschnitt 6.2).

Tabelle 18 generic Secondary DirectoryEntry Template

Feldname

Offset-

(Byte)

Größe

(Byte)

 Kommentare
Eintragstyp 0 1 Dieses Feld ist obligatorisch, und Abschnitt Abschnitt 6.4.1 definiert seinen Inhalt.
GeneralSecondaryFlags 1 1 Dieses Feld ist obligatorisch und Abschnitt 6.4.2 definiert seinen Inhalt.
CustomDefined 2 18 Dieses Feld ist obligatorisch und Strukturen, die von dieser Vorlage abgeleitet sind, definieren ihren Inhalt.
FirstCluster 20 4 Dieses Feld ist obligatorisch und Abschnitt 6.4.3 definiert seinen Inhalt.
Datenlänge 24 8 Dieses Feld ist obligatorisch und Abschnitt 6.4.4 definiert seinen Inhalt.

6.4.1 EntryType Field

Das Feld "EntryType" entspricht der Definition in der Vorlage "Generic DirectoryEntry" (siehe Abschnitt 6.2.1)

6.4.1.1 TypeCode-Feld

Das Feld "TypeCode" muss der definition entsprechen, die in der Vorlage "Generic DirectoryEntry" angegeben ist (siehe Abschnitt 6.2.1.1).

6.4.1.2 TypeImportance-Feld

Das Feld "TypeImportance" entspricht der Definition in der Vorlage "Generic DirectoryEntry" (siehe Abschnitt 6.2.1.2).

6.4.1.2.1 Kritische sekundäre Verzeichniseinträge

Kritische sekundäre Verzeichniseinträge enthalten Informationen, die für die ordnungsgemäße Verwaltung des enthaltenen Verzeichniseintragssatzes von entscheidender Bedeutung sind. Während die Unterstützung für einen bestimmten kritischen sekundären Verzeichniseintrag optional ist, rendert ein unbekannter kritischer Verzeichniseintrag den gesamten Verzeichniseintragssatz als nicht erkannt (über die Definition der anwendbaren Verzeichniseintragsvorlagen hinaus).

Wenn ein Verzeichniseintragssatz jedoch mindestens einen kritischen sekundären Verzeichniseintrag enthält, den eine Implementierung nicht erkennt, interpretiert die Implementierung die Vorlagen der Verzeichniseinträge im Verzeichniseintragssatz höchstens und nicht die Daten, die einem Verzeichniseintrag im Verzeichniseintragssatz zugeordnet sind, enthalten (Dateiverzeichniseinträge sind eine Ausnahme, siehe Abschnitt 7.4).

6.4.1.2.2 Gutartige Sekundärverzeichniseinträge

Gutartige sekundäre Verzeichniseinträge enthalten zusätzliche Informationen, die für die Verwaltung des enthaltenen Verzeichniseintragssatzes nützlich sein können. Die Unterstützung für einen bestimmten gutartigen sekundären Verzeichniseintrag ist optional. Nicht erkannte nicht erkannte sekundäre Verzeichniseinträge rendern nicht den gesamten Verzeichniseintrag, der als nicht erkannt festgelegt wurde.

Implementierungen können alle gutartigen sekundären Einträge ignorieren, die nicht erkannt werden.

6.4.1.3 TypKategorie-Feld

Das Feld "TypeCategory" entspricht der Definition in der Vorlage "Generic DirectoryEntry" (siehe Abschnitt 6.2.1.3).

Für diese Vorlage ist der gültige Wert für dieses Feld 1.

6.4.1.4 InUse-Feld

Das Feld "InUse" entspricht der Definition in der Vorlage "Generic DirectoryEntry" (siehe Abschnitt 6.2.1.4).

6.4.2 GeneralSecondaryFlags Field

Das Feld "GeneralSecondaryFlags" enthält Flags (siehe Tabelle 19).

Tabelle 19 Allgemeine GeneralSecondaryFlags-Feldstruktur

Feldname

Offset-

(Bit)

Größe

(Bits)

 Kommentare
ZuweisungMöglich 0 1 Dieses Feld ist obligatorisch und Abschnitt 6.4.2.1 definiert seinen Inhalt.
NoFatChain 1 1 Dieses Feld ist obligatorisch und Abschnitt 6.4.2.2 definiert seinen Inhalt.
CustomDefined 2 6 Dieses Feld ist obligatorisch und Strukturen, die von dieser Vorlage abgeleitet werden, können dieses Feld definieren.
6.4.2.1 ZuweisungMöglichkeitsfeld

Das Feld "AllocationPossible" hat dieselbe Definition wie das feld mit demselben Namen in der Vorlage "Generic Primary DirectoryEntry" (siehe Abschnitt 6.3.4.1).

6.4.2.2 NoFatChain-Feld

Das Feld "NoFatChain" muss dieselbe Definition wie dasselbe benannte Feld in der Vorlage "Generic Primary DirectoryEntry" haben (siehe Abschnitt 6.3.4.2).

6.4.3 FirstCluster Field

Das Feld "FirstCluster" muss der definition entsprechen, die in der Vorlage "Generic DirectoryEntry" angegeben ist (siehe Abschnitt 6.2.2).

Wenn das NoFatChain-Bit 1 ist, muss FirstCluster auf einen gültigen Cluster im Cluster heap zeigen.

6.4.4 Datenlängenfeld

Das Feld "DataLength" entspricht der definition, die in der Vorlage "Generic DirectoryEntry" angegeben ist (siehe Abschnitt 6.2.3).

Wenn das NoFatChain-Bit 1 ist, darf "DataLength" nicht null sein. Wenn das Feld "FirstCluster" null ist, muss "DataLength" ebenfalls null sein.

7 Verzeichniseintragsdefinitionen

Revision 1.00 des exFAT-Dateisystems definiert die folgenden Verzeichniseinträge:

7.1 Zuordnungs-Bitmapverzeichniseintrag

Im ExFAT-Dateisystem beschreibt ein FAT nicht den Zuordnungszustand von Clustern; stattdessen führt eine Zuordnungsbitmap aus. Zuordnungsbitmaps sind im Cluster-Heap vorhanden (siehe Abschnitt 7.1.5) und weisen entsprechende wichtige primäre Verzeichniseinträge im Stammverzeichnis auf (siehe Tabelle 20).

Das Feld "NumberOfFats" bestimmt die Anzahl der gültigen Zuordnungsbitbit-Verzeichniseinträge im Stammverzeichnis. Wenn das Feld "NumberOfFats" den Wert 1 enthält, ist die einzige gültige Anzahl der Zuordnungs-Bitmap-Verzeichniseinträge 1. Darüber hinaus ist der ein Zuordnungs-Bitmap-Verzeichniseintrag nur gültig, wenn er die erste Zuordnungsbitmap beschreibt (siehe Abschnitt 7.1.2.1). Wenn das Feld "NumberOfFats" den Wert 2 enthält, ist die einzige gültige Anzahl der Zuordnungs-Bitmap-Verzeichniseinträge 2. Außerdem sind die beiden Zuordnungsbitmap-Verzeichniseinträge nur gültig, wenn eine die Erste Zuordnungsbitmap beschreibt und die zweite Zuordnungsbitmap beschreibt.

Tabelle 20 Zuordnung Bitmap DirectoryEntry Structure

Feldname

Offset-

(Byte)

Größe

(Byte)

 Kommentare
Eintragstyp 0 1 Dieses Feld ist obligatorisch und Abschnitt 7.1.1 definiert seinen Inhalt.
BitmapFlags 1 1 Dieses Feld ist obligatorisch und Abschnitt 7.1.2 definiert seinen Inhalt.
Reserviert 2 18 Dieses Feld ist obligatorisch, und der Inhalt ist reserviert.
FirstCluster 20 4 Dieses Feld ist obligatorisch und Abschnitt 7.1.3 definiert seinen Inhalt.
Datenlänge 24 8 Dieses Feld ist obligatorisch und Abschnitt 7.1.4 definiert seinen Inhalt.

7.1.1 EntryType Field

Das Feld "EntryType" muss der definition entsprechen, die in der Vorlage "Generic Primary DirectoryEntry" angegeben ist (siehe Abschnitt 6.3.1).

7.1.1.1 TypeCode-Feld

Das Feld "TypeCode" muss der definition entsprechen, die in der Vorlage "Generic Primary DirectoryEntry" angegeben ist (siehe Abschnitt 6.3.1.1).

Für einen Zuordnungsbitmap-Verzeichniseintrag ist der gültige Wert für dieses Feld 1.

7.1.1.2 TypeImportance-Feld

Das Feld "TypeImportance" entspricht der Definition in der Vorlage "Generic Primary DirectoryEntry" (siehe Abschnitt 6.3.1.2).

Für einen Zuordnungs-Bitmap-Verzeichniseintrag ist der gültige Wert für dieses Feld 0.

7.1.1.3 Typkategorie-Feld

Das Feld "TypeCategory" entspricht der Definition in der Vorlage "Generic Primary DirectoryEntry" (siehe Abschnitt 6.3.1.3).

7.1.1.4 InUse-Feld

Das Feld "InUse" muss der Definition entsprechen, die in der Vorlage "Generic Primary DirectoryEntry" angegeben ist (siehe Abschnitt 6.3.1.4).

7.1.2 BitmapFlags-Feld

Das BitmapFlags-Feld enthält Flags (siehe Tabelle 21).

Tabelle 21 BitmapFlags-Feldstruktur

Feldname

Offset-

(Bit)

Größe

(Bits)

 Kommentare
BitmapIdentifier 0 1 Dieses Feld ist obligatorisch und Abschnitt 7.1.2.1 definiert seinen Inhalt.
Reserviert 1 7 Dieses Feld ist obligatorisch, und der Inhalt ist reserviert.
7.1.2.1 BitmapIdentifier-Feld

Das Feld "BitmapIdentifier" gibt an, welche Zuordnungsbitmap den angegebenen Verzeichniseintrag beschreibt. Implementierungen müssen die First Allocation Bitmap in Verbindung mit dem ersten FAT verwenden und die zweite Zuordnungsbitmap in Verbindung mit dem zweiten FAT verwenden. Das Feld "ActiveFat" beschreibt, welche FAT- und Zuordnungsbitmap aktiv sind.

Die gültigen Werte für dieses Feld sind:

  • 0, was bedeutet, dass der angegebene Verzeichniseintrag die First Allocation Bitmap beschreibt
  • 1, was bedeutet, dass der angegebene Verzeichniseintrag die Second Allocation Bitmap beschreibt und nur möglich ist, wenn NumberOfFats den Wert 2 enthält.

7.1.3 FirstCluster Field

Das Feld "FirstCluster" muss der definition entsprechen, die in der Vorlage "Generic Primary DirectoryEntry" angegeben ist (siehe Abschnitt 6.3.5).

Dieses Feld enthält den Index des ersten Clusters der Clusterkette, wie die FAT beschreibt, die die Zuordnungsbitmap hostet.

7.1.4 DataLength-Feld

Das Feld "DataCluster" muss der definition entsprechen, die in der Vorlage "Generic Primary DirectoryEntry" angegeben ist (siehe Abschnitt 6.3.6).

7.1.5-Zuordnungsbitmap

Eine Zuordnungsbitmap zeichnet den Zuordnungsstatus der Cluster im Cluster heap auf. Jedes Bit in einer Zuordnungsbitmap gibt an, ob der entsprechende Cluster für die Zuordnung verfügbar ist oder nicht.

Eine Zuordnungsbitmap stellt Cluster vom niedrigsten bis zum höchsten Index dar (siehe Tabelle 22). Aus historischen Gründen hat der erste Cluster Index 2.

Hinweis

Das erste Bit in der Bitmap ist das Bit der niedrigsten Reihenfolge des ersten Bytes.

Tabelle 22 Zuordnung Bitmapstruktur

Feldname

Offset-

(Bit)

Größe

(Bits)

 Kommentare
BitmapEntry[2] 0 1 Dieses Feld ist obligatorisch und Abschnitt Abschnitt 7.1.5.1 definiert seinen Inhalt.

.

.

.

.

.

.

.

.

.

.

.

.
BitmapEntry[ClusterCount+1] ClusterCount - 1 1

Dieses Feld ist obligatorisch und Abschnitt 7.1.5.1 definiert seinen Inhalt.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide das ClusterCount-Feld.
Reserviert ClusterCount (DataLength * 8) – ClusterCount

Dieses Feld ist obligatorisch, und der Inhalt ist ggf. reserviert.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide das ClusterCount-Feld.
7.1.5.1 BitmapEntry[2] ... BitmapEntry[ClusterCount+1] Felder

Jedes BitmapEntry-Feld in diesem Array stellt einen Cluster im Cluster-Heap dar. BitmapEntry[2] stellt den ersten Cluster im Cluster heap und BitmapEntry[ClusterCount+1] für den letzten Cluster im Cluster heap dar.

Die gültigen Werte für diese Felder sind:

  • 0, der den entsprechenden Cluster als verfügbar für die Zuordnung beschreibt
  • 1, der den entsprechenden Cluster als nicht für die Zuordnung verfügbar beschreibt (eine Clusterzuordnung kann bereits den entsprechenden Cluster verbrauchen oder das aktive FAT den entsprechenden Cluster als schlecht bezeichnen)

7.2 Verzeichniseintrag im Groß-/Kleinschreibungsverzeichnis

Die Groß-/Kleinschreibungstabelle definiert die Konvertierung von Kleinbuchstaben in Groß-/Kleinbuchstaben. Dies ist aufgrund des Verzeichniseintrags "Dateiname" (siehe Abschnitt 7.7) mit Unicode-Zeichen und dem exFAT-Dateisystem, bei dem die Groß- und Kleinschreibung nicht beachtet wird, wichtig. Die Groß-/Kleinschreibungstabelle ist im Cluster heap vorhanden (siehe Abschnitt 7.2.5) und verfügt über einen entsprechenden wichtigen primären Verzeichniseintrag im Stammverzeichnis (siehe Tabelle 23). Die gültige Anzahl der Einträge im Verzeichnis des Up-Case-Verzeichnisses ist 1.

Aufgrund der Beziehung zwischen der Groß-/Kleinschreibungstabelle und Dateinamen sollten Implementierungen die Groß-/Kleinschreibungstabelle nicht ändern, außer aufgrund von Formatvorgängen.

Tabelle 23 Table DirectoryEntry Structure

Feldname

Offset-

(Byte)

Größe

(Byte)

 Kommentare
Eintragstyp 0 1 Dieses Feld ist obligatorisch und Abschnitt 7.2.1 definiert seinen Inhalt.
Reserviert1 1 3 Dieses Feld ist obligatorisch, und der Inhalt ist reserviert.
TableChecksum 4 4 Dieses Feld ist obligatorisch und Abschnitt 7.2.2 definiert seinen Inhalt.
Reserviert2 8 12 Dieses Feld ist obligatorisch, und der Inhalt ist reserviert.
FirstCluster 20 4 Dieses Feld ist obligatorisch und Abschnitt 7.2.3 definiert seinen Inhalt.
Datenlänge 24 8 Dieses Feld ist obligatorisch und Abschnitt 7.2.4 definiert seinen Inhalt.

7.2.1 EntryType Field

Das Feld "EntryType" muss der definition entsprechen, die in der Vorlage "Generic Primary DirectoryEntry" angegeben ist (siehe Abschnitt 6.3.1).

7.2.1.1 TypeCode-Feld

Das Feld "TypeCode" muss der definition entsprechen, die in der Vorlage "Generic Primary DirectoryEntry" angegeben ist (siehe Abschnitt 6.3.1.1).

Für den Eintrag "Tabelle im Up-Case-Verzeichnis" ist der gültige Wert für dieses Feld "2".

7.2.1.2 TypeImportance-Feld

Das Feld "TypeImportance" entspricht der Definition in der Vorlage "Generic Primary DirectoryEntry" (siehe Abschnitt 6.3.1.2).

Für den Eintrag "Tabelle nach oben" ist der gültige Wert für dieses Feld 0.

7.2.1.3 TypeCategory Field

Das Feld "TypeCategory" entspricht der Definition in der Vorlage "Generic Primary DirectoryEntry" (siehe Abschnitt 6.3.1.3).

7.2.1.4 InUse Field

Das Feld "InUse" muss der Definition entsprechen, die in der Vorlage "Generic Primary DirectoryEntry" angegeben ist (siehe Abschnitt 6.3.1.4).

7.2.2 TableChecksum Field

Das Feld "TableChecksum" enthält die Prüfsumme der Tabelle "Up-case" (die die Felder "FirstCluster" und "DataLength" beschreiben). Die Implementierungen überprüfen, ob der Inhalt dieses Felds gültig ist, bevor die Up-Case-Tabelle verwendet wird.

Abbildung 3 TableChecksum-Berechnung

UInt32 TableChecksum
(
    UCHAR  * Table,    // points to an in-memory copy of the up-case table
    UInt64   DataLength
)
{
    UInt32 Checksum = 0;
    UInt64 Index;

    for (Index = 0; Index < DataLength; Index++)
    {
        Checksum = ((Checksum&1) ? 0x80000000 : 0) + (Checksum>>1) + (UInt32)Table[Index];
    }

    return Checksum;
}

7.2.3 FirstCluster Field

Das Feld "FirstCluster" muss der definition entsprechen, die in der Vorlage "Generic Primary DirectoryEntry" angegeben ist (siehe Abschnitt 6.3.5).

Dieses Feld enthält den Index des ersten Clusters der Clusterkette, wie die FAT beschreibt, die die Up-Case-Tabelle hostet.

7.2.4 DataLength Field

Das Feld "DataCluster" muss der definition entsprechen, die in der Vorlage "Generic Primary DirectoryEntry" angegeben ist (siehe Abschnitt 6.3.6).

7.2.5 Tabelle für Groß-/Kleinschreibung

Eine Up-Case-Tabelle ist eine Reihe von Unicode-Zeichenzuordnungen. Eine Zeichenzuordnung besteht aus einem 2-Byte-Feld, wobei der Index des Felds in der Groß-/Kleinschreibungstabelle das Unicode-Zeichen darstellt, das groß geschrieben werden soll, und das 2-Byte-Feld, das das groß geschriebene Unicode-Zeichen darstellt.

Die ersten 128 Unicode-Zeichen weisen obligatorische Zuordnungen auf (siehe Tabelle 24). Eine Groß-/Kleinschreibungstabelle mit einer anderen Zeichenzuordnung für eines der ersten 128 Unicode-Zeichen ist ungültig.

Implementierungen, die nur Zeichen aus dem obligatorischen Zuordnungsbereich unterstützen, können die Zuordnungen der restlichen Falltabelle ignorieren. Solche Implementierungen dürfen nur Zeichen aus dem obligatorischen Zuordnungsbereich verwenden, wenn Dateien erstellt oder umbenannt werden (siehe Abschnitt 7.7). Bei der Groß-/Kleinschreibung vorhandener Dateinamen dürfen solche Implementierungen keine Groß-/Kleinschreibung aus dem nicht obligatorischen Zuordnungsbereich aufweisen, bleiben aber im resultierenden Dateinamen unverändert (dies ist eine partielle Groß-/Kleinschreibung). Beim Vergleich von Dateinamen müssen solche Implementierungen Dateinamen behandeln, die sich von dem namen unterscheiden, der sich nur von Unicode-Zeichen vom nicht obligatorischen Zuordnungsbereich unterscheidet. Obwohl solche Dateinamen nur potenziell gleichwertig sind, können solche Implementierungen nicht sicherstellen, dass der vollständig im Groß-/Kleinschreibung enthaltene Dateiname nicht mit dem namen im Vergleich kollidiert.

Tabelle 24 Obligatorische erste 128 Einträge der Groß-/Kleinschreibung

Tabellenindex + 0 + 1 + 2 + 3 + 4 + 5 + 6 + 7
0000h 0000h 0001h 0002h 0003h 0004h 0005h 0006h 0007h
0008h 0008h 0009h 000Ah 000Bh 000Ch 000Dh 000Eh 000Fh
0010h 0010h 0011h 0012h 0013h 0014h 0015h 0016h 0017h
0018h 0018h 0019h 001Ah 001Bh 001Ch 001Dh 001Eh 001Fh
0020h 0020h 0021h 0022h 0023h 0024h 0025h 0026h 0027h
0028h 0028h 0029h 002Ah 002Bh 002Ch 002Dh 002Eh 002Fh
0030h 0030h 0031h 0032h 0033h 0034h 0035h 0036h 0037h
0038h 0038h 0039h 003Ah 003Bh 003Ch 003Dh 003Eh 003Fh
0040h 0040h 0041h 0042h 0043h 0044h 0045h 0046h 0047h
0048h 0048h 0049h 004Ah 004Bh 004Ch 004Dh 004Eh 004Fh
0050h 0050h 0051h 0052h 0053h 0054h 0055h 0056h 0057h
0058h 0058h 0059h 005Ah 005Bh 005Ch 005Dh 005Eh 005Fh
0060h 0060h 0041h 0042h 0043h 0044h 0045h 0046h 0047h
0068h 0048h 0049h 004Ah- 004Bh- 004Ch- 004Dh- 004Eh- 004Fh-
0070h 0050h 0051h 0052h 0053h 0054h 0055h 0056h 0057h
0078h 0058h 0059h 005Ah- 007Bh 007Ch 007Dh 007Eh 007Fh

(Hinweis: Einträge mit nicht identitätsfreien Groß-/Kleinschreibungszuordnungen sind fett formatiert)

Beim Formatieren eines Volumes können Implementierungen eine Groß-/Kleinschreibungstabelle in einem komprimierten Format mithilfe der Identitätszuordnungskomprimierung generieren, da ein großer Teil des Unicode-Zeichenbereichs kein Konzept der Groß-/Kleinschreibung aufweist (was bedeutet, dass die Zeichen "Kleinschreibung" und "Groß-/Kleinschreibung" gleichwertig sind). Implementierungen komprimieren eine Groß-/Kleinschreibungstabelle, indem eine Reihe von Identitätszuordnungen mit dem Wert FFFFh dargestellt wird, gefolgt von der Anzahl der Identitätszuordnungen.

Eine Implementierung kann z. B. die ersten 100 Zeichenzuordnungen (64h) mit den folgenden acht Einträgen einer komprimierten Groß-/Kleinschreibungstabelle darstellen:

FFFFh, 0061h, 0041h, 0042h, 0043h

Die ersten beiden Einträge geben an, dass die ersten 97 (61h) Zeichen (von 0000h bis 0060h) Identitätszuordnungen aufweisen. Die nachfolgenden Zeichen, 0061h bis 0063h, ordnen die Zeichen 0041h bis 0043h bzw. 0043h zu.

Die Möglichkeit, eine komprimierte Groß-/Kleinschreibungstabelle beim Formatieren eines Volumes bereitzustellen, ist optional. Die Möglichkeit, sowohl eine nicht komprimierte als auch eine komprimierte Falltabelle zu interpretieren, ist jedoch obligatorisch. Der Wert des Felds "TableChecksum" entspricht immer der Art, wie die Groß-/Kleinschreibungstabelle auf dem Volume vorhanden ist, die entweder komprimiert oder nicht komprimiert sein kann.

Beim Formatieren eines Volumes sollten Implementierungen die empfohlene Groß-/Kleinschreibungstabelle im komprimierten Format aufzeichnen (siehe Tabelle 25), für die der Wert des Felds "TableChecksum" E619D30Dh lautet.

Wenn eine Implementierung eine eigene up-case-Tabelle definiert, entweder komprimiert oder unkomprimiert, muss diese Tabelle den vollständigen Unicode-Zeichenbereich abdecken (von Zeichencodes 0000h bis einschließlich FFFFh).