exFAT-Dateisystemspezifikation

  • Artikel

1 Einführung

Das exFAT-Dateisystem ist der Nachfolger von FAT32 in der FAT-Dateisystemfamilie. Diese Spezifikation beschreibt das exFAT-Dateisystem und enthält alle Informationen, die für die Implementierung des exFAT-Dateisystems erforderlich sind.

1.1 Entwurfsziele

Das exFAT-Dateisystem hat drei zentrale Entwurfsziele (siehe Liste unten).

  1. Behalten Sie die Einfachheit von FAT-basierten Dateisystemen bei.

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

  2. Aktivieren Sie sehr große Dateien und Speichergeräte.

    Das exFAT-Dateisystem verwendet 64 Bits, 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 Cluster mit einer Größe von bis zu 32 MB und ermöglicht somit sehr große Speichergeräte.

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

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

1.2 Spezifische Terminologie

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

Tabelle 1 Definition von Begriffen, die eine sehr spezifische Bedeutung haben

Begriff Definition
Soll In dieser Spezifikation wird der Begriff "shall" verwendet, um ein Verhalten zu beschreiben, das obligatorisch ist.
Optional Diese Spezifikation verwendet den Begriff "sollte", um ein Verhalten zu beschreiben, das sie dringend empfiehlt, aber nicht obligatorisch macht.
May In dieser Spezifikation wird der Begriff "may" verwendet, um ein optionales Verhalten zu beschreiben.
Obligatorisch. Dieser Begriff beschreibt ein Feld oder eine Struktur, das von einer Implementierung geändert werden soll, und muss gemäß der Beschreibung dieser Spezifikation interpretiert werden.
Optional Dieser Begriff beschreibt ein Feld oder eine Struktur, die 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 entsprechend der Beschreibung ändern und interpretieren.
Nicht definiert Dieser Begriff beschreibt Feld- oder Strukturinhalte, die eine Implementierung bei Bedarf ändern kann (d. h. beim Festlegen von umgebenden Feldern oder Strukturen klar auf Null) und darf nicht so interpretiert werden, dass sie eine bestimmte Bedeutung haben.
Reserviert

Dieser Begriff beschreibt Feld- oder Strukturinhalte, die Folgendes implementieren:

  1. Initialisieren auf 0 (null) und dürfen nicht für irgendeinen Zweck verwendet werden

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

  3. Beibehalten von Vorgängen, die umgebende Felder oder Strukturen verändern

1.3 Volltext allgemeiner Akronyme

Diese Spezifikation verwendet Akronyme, die in der Pc-Industrie häufig verwendet werden (siehe Tabelle 2).

Tabelle 2 Volltext allgemeiner Akronyme

Akronym Volltext
ASCII Amerikanischer Standardcode für Den Informationsaustausch
BIOS Basic Input Output System
CPU Zentrale Verarbeitungseinheit
exFAT Erweiterbare Dateizuordnungstabelle
FAT 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 Interrupt
MBR Master Boot Record
texFAT Transaktionssichere exFAT
UTC Koordinierte Weltzeit (UTC)

1.4 Standardfeld- und Strukturqualifizierer

Felder und Strukturen in dieser Spezifikation verfügen über die folgenden Qualifizierer (siehe Liste unten), es sei denn, die Spezifikation weist etwas anderes auf.

  1. Sind nicht signiert

  2. Verwenden Sie die Dezimalschreibweise, um Werte zu beschreiben, sofern nicht anders angegeben; Diese Spezifikation verwendet den Nachbehebungsbuchstaben "h", um hexadezimale Zahlen anzugeben und GUIDs in geschweifte Klammern einzuschließen.

  3. Sind im Little-Endian-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 auf dem Basisdateisystem hinzufügt. TexFAT wird von Windows CE verwendet. TexFAT erfordert die Verwendung der beiden FATs und Zuordnungsbitbits für die Verwendung in Transaktionen. Außerdem werden mehrere zusätzliche Strukturen definiert, einschließlich Auffüllungsdeskriptoren und Sicherheitsdeskriptoren.

2 Volumestruktur

Ein Volume ist der Satz aller Dateisystemstrukturen und des Datenspeichers, der zum Speichern und Abrufen von Benutzerdaten erforderlich ist. Alle exFAT-Volumes enthalten vier Regionen (siehe Tabelle 3).

Tabelle 3 Volumestruktur

Name der Unterregion

Offset

(Sektor)

Größe

(Sektoren)

 Kommentare
Hauptstartregion
Hauptstartsektor 0 1 Dieser Unterbereich ist obligatorisch, und in Abschnitt 3.1 wird der Inhalt definiert.
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 in Abschnitt 3.3 wird derEn Inhalt definiert.
Haupt reserviert 10 1 Diese Unterregion ist obligatorisch, und ihr Inhalt ist reserviert.
Hauptstartprüfsumme 11 1 Diese Unterregion ist obligatorisch, und in Abschnitt 3.4 wird derEn Inhalt definiert.
Sicherungsstartregion
Sicherungsstartsektor 12 1 Diese Unterregion ist obligatorisch, und in Abschnitt 3.1 wird derEn Inhalt definiert.
Erweiterte Startsektoren sichern 13 8 Diese Unterregion ist obligatorisch, und abschnitt 3.2 definiert den Inhalt.
OEM-Parameter für die Sicherung 21 1 Diese Unterregion ist obligatorisch, und in Abschnitt 3.3 wird derEn Inhalt definiert.
Reservierte Sicherung 22 1 Diese Unterregion ist obligatorisch, und ihr Inhalt ist reserviert.
Sicherungsstart-Prüfsumme 23 1 Diese Unterregion ist obligatorisch, und in Abschnitt 3.4 wird derEn Inhalt definiert.
FAT-Region
FAT-Ausrichtung 24 FatOffset – 24

Diese Unterregion ist obligatorisch, und ihr Inhalt ist, falls vorhanden, nicht definiert.

Hinweis: Der Haupt- und der Sicherungsstartsektor enthalten das Feld FatOffset.
Erste FAT FatOffset FatLength

Diese Unterregion ist obligatorisch, und abschnitt 4.1 definiert den Inhalt.

Hinweis: Der Haupt- und der Sicherungsstartsektor enthalten die Felder FatOffset und FatLength.
Zweites FAT FatOffset + FatLength FatLength * (NumberOfFats – 1)

Diese Unterregion ist obligatorisch, und in Abschnitt 4.1 wird der Inhalt definiert, falls vorhanden.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide die Felder FatOffset, FatLength und NumberOfFats. Das Feld NumberOfFats darf nur die Werte 1 und 2 enthalten.
Datenregion
Clusterheapausrichtung FatOffset + FatLength * NumberOfFats ClusterHeapOffset – (FatOffset + FatLength * NumberOfFats)

Diese Unterregion ist obligatorisch, und ihr Inhalt ist, falls vorhanden, nicht definiert.

Hinweis: Der Haupt- und der Sicherungsstartsektor enthalten die Felder FatOffset, FatLength, NumberOfFats und ClusterHeapOffset. Die gültigen Werte des Felds NumberOfFats sind 1 und 2.
Clusterheap ClusterHeapOffset ClusterCount * 2SectorsPerClusterShift

Diese Unterregion ist obligatorisch, und abschnitt 5.1 definiert den Inhalt.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide die Felder ClusterHeapOffset, ClusterCount und SectorsPerClusterShift.
Überschüssiger Speicherplatz ClusterHeapOffset + ClusterCount * 2SectorsPerClusterShift VolumeLength – (ClusterHeapOffset + ClusterCount * 2SectorsPerClusterShift)

Diese Unterregion ist obligatorisch, und ihr Inhalt ist, falls vorhanden, nicht definiert.

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

3 Haupt- und Sicherungsstartregionen

Der Hauptstartbereich enthält alle erforderlichen Startumreifungsanweisungen, Identifizieren von Informationen und Dateisystemparametern, damit eine Implementierung Folgendes ausführen kann:

  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.

Die Sicherungsstartregion ist eine Sicherung der Hauptstartregion. Es unterstützt die Wiederherstellung des exFAT-Volumes, wenn sich die Main Boot-Region in einem inkonsistenten Zustand befindet. Außer in seltenen Fällen, z. B. beim Aktualisieren von Startumreifungsanweisungen, sollten Implementierungen den Inhalt der Sicherungsstartregion nicht ändern.

3.1 Haupt- und Sicherungsstartsektor-Unterregionen

Der Hauptstartsektor enthält Code für die Startumreifung von einem exFAT-Volume und grundlegende exFAT-Parameter, die die Volumestruktur beschreiben (siehe Tabelle 4). BIOS, MBR oder andere Startumreifungs-Agents können diesen Sektor untersuchen und alle darin enthaltenen Startumreifungsanweisungen laden und ausführen.

Der Sicherungsstartsektor ist eine Sicherung des Hauptstartsektors und weist die gleiche Struktur auf (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 müssen Implementierungen ihren Inhalt überprüfen, indem sie ihre jeweilige Startprüfsumme überprüfen und sicherstellen, dass sich alle felder innerhalb ihres gültigen Wertbereichs befinden.

Während der anfängliche Formatvorgang den Inhalt des Haupt- und Sicherungsstartsektors initialisiert, können Implementierungen diese Sektoren bei Bedarf aktualisieren (und auch die 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: Struktur des Haupt- und Sicherungsstartsektors

Feldname

Offset

(Byte)

Größe

(Bytes)

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

Dieses Feld ist obligatorisch, und sein Inhalt ist, falls vorhanden, nicht definiert.

Hinweis: Der Haupt- und der Sicherungsstartsektor enthalten das Feld BytesPerSectorShift.

3.1.1 JumpBoot-Feld

Das JumpBoot-Feld muss die Sprunganweisung für CPUs enthalten, die auf PCs üblich sind, die bei Ausführung die CPU "springt", um die Boot-Umreifungsanweisungen im BootCode-Feld auszuführen.

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

3.1.2 FileSystemName Field

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", was drei nachfolgende Leerzeichen enthält.

3.1.3 MustBeZero Field

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

Der gültige Wert für dieses Feld ist 0, wodurch verhindert wird, dass FAT12/16/32-Implementierungen versehentlich ein exFAT-Volume einbinden.

3.1.4 PartitionOffset-Feld

Das Feld PartitionOffset muss den medienrelativen Sektoroffset der Partition beschreiben, die das angegebene exFAT-Volume hostet. Dieses Feld unterstützt das Starten des Volumes mithilfe des erweiterten INT 13h auf PCs.

Alle möglichen Werte für dieses Feld sind gültig. der Wert 0 gibt jedoch an, dass Implementierungen dieses Feld ignorieren müssen.

3.1.5 VolumeLength Field

Das Feld VolumeLength muss die Größe des angegebenen exFAT-Volumens in Sektoren beschreiben.

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

  • Mindestens 220/2BytesPerSectorShift, wodurch sichergestellt wird, dass das kleinste Volume mindestens 1 MB beträgt.

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

    Wenn die Größe des Unterbereichs "Überschüssiger Speicherplatz" 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 Sektoroffset des ersten FAT. In diesem Feld können Implementierungen die erste FAT an den Merkmalen der zugrunde liegenden Speichermedien ausrichten.

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

  • Mindestens 24, in denen die Sektoren der Hauptstart- und Sicherungsstartregionen verwendet werden

  • Höchstens ClusterHeapOffset - (FatLength * NumberOfFats), das die Sektoren erfasst, die der Clusterheap verbraucht

3.1.7 FatLength Field

Das Feld FatLength muss die Länge jeder FAT-Tabelle in Sektoren beschreiben (das Volumen kann bis zu zwei FATs enthalten).

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

  • Mindestens (ClusterCount + 2) * 22/2BytesPerSectorShiftwird auf die nächste ganze Zahl aufgerundet, wodurch sichergestellt wird, dass jede FAT über ausreichend Speicherplatz zum Beschreiben aller Cluster im Clusterheap verfügt.

  • Höchstens (ClusterHeapOffset - FatOffset) / NumberOfFats auf die nächste ganze Zahl gerundet, wodurch sichergestellt wird, dass die FATs vor dem Clusterheap vorhanden sind.

Dieses Feld kann einen Wert enthalten, der über seine untere Grenze (wie oben beschrieben) hinaus liegt, damit die zweite FAT, falls vorhanden, auch an den Merkmalen des zugrunde liegenden Speichermediums ausgerichtet werden kann. Der Inhalt des Raums, der über den vom FAT selbst benötigten Wert hinausgeht, ist nicht definiert.

3.1.8 ClusterHeapOffset-Feld

Das Feld ClusterHeapOffset muss den volumenrelativen Sektoroffset des Clusterheaps beschreiben. Mit diesem Feld können Implementierungen den Clusterheap an den Merkmalen der zugrunde liegenden Speichermedien ausrichten.

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

  • Mindestens FatOffset + FatLength * NumberOfFats, um die Sektoren zu berücksichtigen, die alle vorherigen Regionen verbrauchen

  • Höchstens 232-1 oder VolumeLength - (ClusterCount * 2SectorsPerClusterShift), je nachdem, welche Berechnung kleiner ist

3.1.9 ClusterCount Field

Das Feld ClusterCount muss die Anzahl von Clustern beschreiben, die der Clusterheap enthält.

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

  • (VolumeLength - ClusterHeapOffset) / 2SectorsPerClusterShiftgerundet auf die nächste ganze Zahl, die genau die Anzahl von Clustern ist, die zwischen dem Anfang des Clusterheaps und dem Ende des Volumes passen können.

  • 232-11, die maximale Anzahl von Clustern, die ein FAT beschreiben kann

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

3.1.10 FirstClusterOfRootDirectory-Feld

Das Feld FirstClusterOfRootDirectory muss den Clusterindex des ersten Clusters des Stammverzeichnisses enthalten. Implementierungen sollten alle Anstrengungen unternehmen, um den ersten Cluster des Stammverzeichnisses im ersten nicht fehlerhaften Cluster nach den Clustern zu platzieren, die die Zuordnungsbitbit und die Up-Case-Tabelle nutzen.

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

  • Mindestens 2, der Index des ersten Clusters im Clusterheap

  • Höchstens ClusterCount + 1, der Index des letzten Clusters im Clusterheap

3.1.11 VolumeSerialNumber Field

Das VolumeSerialNumber-Feld muss eine eindeutige Seriennummer enthalten. Dies unterstützt Implementierungen bei der Unterscheidung zwischen verschiedenen exFAT-Volumes. Implementierungen sollten die Seriennummer generieren, indem das Datum und die Uhrzeit der Formatierung des exFAT-Volumes kombiniert werden. Der Mechanismus zum Kombinieren von Datum und Uhrzeit zu einer Seriennummer ist implementierungsspezifisch.

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

3.1.12 FileSystemRevision Field

Das Feld FileSystemRevision muss die Haupt- und Nebenrevisionsnummern der exFAT-Strukturen auf dem angegebenen Volume beschreiben.

Das hochgeordnete Byte ist die Hauptrevisionsnummer, und das Byte mit niedriger Ordnung ist die Nebenrevisionsnummer. Wenn das Byte mit hoher Ordnung beispielsweise den Wert 01h und das Byte mit niedriger Reihenfolge den Wert 05h enthält, beschreibt das FileSystemRevision-Feld die Revisionsnummer 1.05. Ebenso beschreibt das Feld FileSystemRevision die Revisionsnummer 10.15, wenn das Byte mit hoher Ordnung den Wert 0Ah enthält und das Byte mit niedriger Reihenfolge den Wert 0Fh enthält.

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

  • Mindestens 0 für das Byte mit niedriger Ordnung und 1 für das Byte hoher Ordnung

  • Höchstens 99 für das Low-Order-Byte und 99 für das hochgeordnete Byte

Die in dieser Spezifikation beschriebene Revisionsnummer von exFAT ist 1,00. Implementierungen dieser Spezifikation sollten jedes exFAT-Volume mit der Hauptrevisionsnummer 1 einbinden und kein exFAT-Volume mit einer anderen größeren Revisionsnummer einbinden. Implementierungen müssen die Nebenrevisionsnummer berücksichtigen und dürfen keine Vorgänge ausführen oder Dateisystemstrukturen erstellen, die nicht in der entsprechenden Spezifikation der angegebenen Nebenrevisionsnummer beschrieben sind.

3.1.13 VolumeFlags-Feld

Das VolumeFlags-Feld muss Flags enthalten, die die status verschiedener Dateisystemstrukturen auf dem exFAT-Volume angeben (siehe Tabelle 5).

Implementierungen dürfen dieses Feld nicht einschließen, wenn die prüfsumme des jeweiligen Hauptstarts oder der Sicherungsstartregion festgelegt wird. Wenn sich auf den Sicherungsstartsektor bezieht, 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 in Abschnitt 3.1.13.1 wird der Inhalt definiert.
VolumeDirty 1 1 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.13.2 wird der Inhalt definiert.
MediaFailure 2 1 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.13.3 wird der Inhalt definiert.
ClearToZero 3 1 Dieses Feld ist obligatorisch, und in Abschnitt 3.1.13.4 wird der Inhalt definiert.
Reserviert 4 12 Dieses Feld ist obligatorisch, und sein Inhalt ist reserviert.
3.1.13.1 ActiveFat Field

Das ActiveFat-Feld muss wie folgt beschreiben, welche FAT- und Zuordnungsbit aktiv sind (und die Implementierungen verwenden müssen):

  • 0, was bedeutet, dass die Bitmap "Erste FAT" und "Erste Zuordnung" aktiv sind.

  • 1, was bedeutet, dass die Zweite FAT- und die zweite Zuordnungsbitbit aktiv sind und nur möglich sind, wenn das Feld NumberOfFats den Wert 2 enthält.

Implementierungen müssen die inaktive FAT- und Zuordnungsbitbit als veraltet betrachten. Nur texFAT-fähige Implementierungen dürfen die aktiven FAT- und Zuordnungsbitbits ändern (siehe Abschnitt 7.1).

3.1.13.2 VolumeDirty Field

Das Feld VolumeDirty muss wie folgt beschreiben, ob das Volume modifiziert ist oder nicht:

  • 0, was bedeutet, dass sich das Volume 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 Dateisystemmetadateninkonsistenzen auftreten, die nicht aufgelöst werden. Wenn beim Einbinden eines Volumes der Wert dieses Felds 1 ist, können nur Implementierungen, die Inkonsistenzen von Dateisystemmetadaten auflösen, den Wert dieses Felds auf 0 löschen. Solche Implementierungen dürfen den Wert dieses Felds erst auf 0 löschen, nachdem sichergestellt ist, dass sich das Dateisystem in einem konsistenten Zustand befindet.

Wenn beim Einbinden eines Volumes der Wert dieses Felds 0 ist, sollten Implementierungen dieses Feld auf 1 festlegen, bevor sie Dateisystemmetadaten aktualisieren und dieses Feld anschließend auf 0 löschen, ähnlich der empfohlenen Schreibreihenfolge, die in Abschnitt 8.1 beschrieben wird.

3.1.13.3 MediaFailure Field

Das Feld MediaFailure muss wie folgt beschreiben, ob eine Implementierung Medienfehler festgestellt hat oder nicht:

  • 0, was bedeutet, dass das Hostmedium keine Fehler gemeldet hat oder bekannte Fehler bereits in der FAT als "schlechte" Cluster aufgezeichnet wurden.

  • 1, was bedeutet, dass das Hostmedium Fehler gemeldet hat (d. h. Lese- oder Schreibvorgänge fehlgeschlagen sind).

Eine Implementierung sollte dieses Feld in folgenden Fällen auf 1 festlegen:

  1. Das Hostmedium versucht nicht, auf eine Region im Volume zuzugreifen.

  2. Die Implementierung verfügt über erschöpfte Zugriffswiebelegorithmen, falls vorhanden.

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

3.1.13.4 ClearToZero-Feld

Das ClearToZero-Feld hat in dieser Spezifikation keine signifikante Bedeutung.

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

  • 0, das keine besondere Bedeutung hat

  • 1, d. h. implementierungen müssen dieses Feld vor der Änderung von Dateisystemstrukturen, Verzeichnissen oder Dateien in 0 löschen.

3.1.14 BytesPerSectorShift-Feld

Das Feld BytesPerSectorShift beschreibt die Bytes pro Sektor, ausgedrückt als Protokoll2(N), wobei N die Anzahl der Bytes pro Sektor ist. Für 512 Bytes pro Sektor ist der Wert dieses Felds beispielsweise 9.

Der gültige Wertebereich für dieses Feld muss sein:

  • Mindestens 9 (Sektorgröße von 512 Bytes), was der kleinste Sektor ist, der für ein ExFAT-Volume möglich ist

  • Höchstens 12 (Sektorgröße von 4.096 Byte), dies ist die Speicherseitengröße von CPUs, die auf PCs üblich sind

3.1.15 SectorsPerClusterShift Field

Das Feld SectorsPerClusterShift beschreibt die Sektoren pro Cluster, ausgedrückt als Protokoll2(N), wobei N die Anzahl der Sektoren pro Cluster ist. Für 8 Sektoren pro Cluster ist der Wert dieses Felds beispielsweise 3.

Der gültige Wertebereich für dieses Feld muss sein:

  • Mindestens 0 (1 Sektor pro Cluster), was der kleinste mögliche Cluster ist

  • Höchstens 25 – BytesPerSectorShift, was eine Clustergröße von 32 MB ergibt

3.1.16 NumberOfFats-Feld

Im Feld NumberOfFats wird die Anzahl von FATs und Zuordnungsbitbits beschrieben, die das Volume enthält.

Der gültige Wertebereich für dieses Feld muss sein:

  • 1, der angibt, dass das Volume nur die Bitmap "First FAT" und "First Allocation" enthält.

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

3.1.17 LaufwerkAuswahlfeld

Das Feld DriveSelect muss die erweiterte INT 13h-Laufwerksnummer enthalten, die das Starten von diesem Volume mithilfe des erweiterten 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 PercentInUse-Feld

Im Feld PercentInUse wird der Prozentsatz der Cluster im Clusterheap beschrieben, die zugeordnet sind.

Der gültige Wertebereich für dieses Feld muss sein:

  • Zwischen 0 und 100 inklusive, d. h. der Prozentsatz der zugeordneten Cluster im Clusterheap, gerundet auf die nächste ganze Zahl

  • Genau FFh, der angibt, dass der Prozentsatz der zugeordneten Cluster im Clusterheap nicht verfügbar ist.

Implementierungen ändern den Wert dieses Felds, um Änderungen in der Zuordnung von Clustern im Clusterheap widerzuspiegeln, oder ändern ihn in FFh.

Implementierungen dürfen dieses Feld bei der Berechnung der jeweiligen Prüfsumme der Region "Hauptstart" oder "Sicherungsstart" nicht enthalten. Wenn auf den Backup Boot-Sektor verwiesen wird, müssen Implementierungen dieses Feld als veraltet betrachten.

3.1.19 BootCode-Feld

Das BootCode-Feld muss Boot-Umreifungsanweisungen enthalten. Implementierungen können dieses Feld mit den CPU-Anweisungen auffüllen, die zum Starten eines Computersystems erforderlich sind. Implementierungen, die keine Boot-Umreifungsanweisungen bereitstellen, müssen jedes Byte in diesem Feld als Teil ihres Formatvorgangs in F4h initialisieren (die Stoppanweisung für CPUs, die auf PCs üblich sind).

3.1.20 BootSignature-Feld

Das Feld BootSignature muss beschreiben, ob die Absicht eines bestimmten Sektors darin besteht, dass es sich um einen Startsektor handelt oder nicht.

Der gültige Wert für dieses Feld ist AA55h. Jeder andere Wert in diesem Feld ungültig den jeweiligen Startsektor. Implementierungen sollten den Inhalt dieses Felds überprüfen, bevor sie von einem anderen Feld im jeweiligen Startsektor abhängig sind.

3.2 Unterregionen für Haupt- und Sicherungsbereiche für erweiterte Startsektoren

Jeder Sektor der Hauptsektoren für erweiterte Startboote hat dieselbe Struktur. Jeder Sektor kann jedoch unterschiedliche Boot-Umreifungsanweisungen enthalten (siehe Tabelle 6). Start-Umreifungs-Agents, z. B. die Boot-Umreifungsanweisungen im Hauptstartsektor, alternative BIOS-Implementierungen oder die Firmware eines eingebetteten Systems, können diese Sektoren laden und die darin enthaltenen Anweisungen ausführen.

Die Sicherungssektoren für erweiterte Startsektoren sind eine Sicherung der Hauptsektoren für erweiterte Starte und verfügen über die gleiche Struktur (siehe Tabelle 6).

Vor der Ausführung der Anweisungen des Haupt- oder Sicherungssektors für den erweiterten Startsektor sollten Implementierungen ihren Inhalt überprüfen, indem sie sicherstellen, dass das Feld ExtendedBootSignature jedes Sektors den vorgeschriebenen Wert enthält.

Während der anfängliche Formatvorgang den Inhalt des Haupt- und Sicherungs-Erweiterten Startsektors initialisiert, können implementierungen diese Sektoren aktualisieren (und müssen auch die jeweilige Startprüfsumme aktualisieren) nach Bedarf.

Tabelle 6: Struktur des erweiterten Startsektors

Feldname

Offset

(Byte)

Größe

(Byte)

 Kommentare
ExtendedBootCode 0 2BytesPerSectorShift – 4

Dieses Feld ist obligatorisch, und in Abschnitt 3.2.1 wird der Inhalt definiert.

Hinweis: Der Haupt- und der Sicherungsstartsektor enthalten beide das Feld BytesPerSectorShift.
ExtendedBootSignature 2BytesPerSectorShift – 4 4

Dieses Feld ist obligatorisch, und in Abschnitt 3.2.2 wird der Inhalt definiert.

Hinweis: Der Haupt- und der Sicherungsstartsektor enthalten beide das Feld BytesPerSectorShift.

3.2.1 ExtendedBootCode-Feld

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

3.2.2 ExtendedBootSignature Field

Das Feld ExtendedBootSignature muss beschreiben, ob die Absicht eines bestimmten Sektors darin besteht, dass es sich um einen erweiterten Startsektor handelt.

Der gültige Wert für dieses Feld ist AA550000h. Jeder andere Wert in diesem Feld ungültig den jeweiligen Main- oder Backup Extended Boot Sector. Implementierungen sollten den Inhalt dieses Felds überprüfen, bevor sie von einem anderen Feld im jeweiligen erweiterten Startsektor abhängig sind.

3.3 Haupt- und Sicherungs-OEM-Parameter unter regionen

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 selbst definiert zwei Parameterstrukturen: NULL-Parameter (siehe Abschnitt 3.3.3) und Blitzparameter (siehe Abschnitt 3.3.4).

Die OEM-Parameter für die Sicherung sind eine Sicherung der OEM-Hauptparameter und haben die gleiche Struktur (siehe Tabelle 7).

Vor der Verwendung des Inhalts der OEM-Parameter "Main" oder "Backup" müssen Implementierungen ihren Inhalt überprüfen, indem sie ihre jeweilige Startprüfsumme überprüfen.

Hersteller sollten die OEM-Parameter Main und Backup mit eigenen benutzerdefinierten Parameterstrukturen (sofern vorhanden) und anderen Parameterstrukturen auffüllen. Nachfolgende Formatvorgänge müssen den Inhalt der OEM-Parameter Main und Backup beibehalten.

Implementierungen können die OEM-Parameter Main und Backup bei Bedarf aktualisieren (und müssen auch die jeweilige Startprüfsumme aktualisieren).

Tabelle 7 OEM-Parameterstruktur

Feldname

Offset

(Byte)

Größe

(Byte)

 Kommentare
Parameter[0] 0 48 Dieses Feld ist obligatorisch, und in Abschnitt 3.3.1 wird der Inhalt definiert.

.

.

.

.

.

.

.

.

.

.

.

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

Dieses Feld ist obligatorisch, und sein Inhalt ist reserviert.

Hinweis: Der Haupt- und der Sicherungsstartsektor enthalten das Feld BytesPerSectorShift.

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). Jedes nicht verwendete Parameterfeld muss so beschrieben werden, dass es eine Null-Parameter-Struktur enthält (siehe Abschnitt 3.3.3).

3.3.2 Vorlage für generische Parameter

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

Tabelle 8 Vorlage für generische Parameter

Feldname

Offset

(Byte)

Größe

(Bytes)

 Kommentare
ParametersGuid 0 16 Dieses Feld ist obligatorisch, und in Abschnitt 3.3.2.1 wird der Inhalt definiert.
CustomDefined 16 32 Dieses Feld ist obligatorisch, und die Strukturen, die von dieser Vorlage abgeleitet werden, definieren den Inhalt.
3.3.2.1 ParameterGuid Field

Das Feld ParametersGuid muss eine GUID beschreiben, 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.exe verwenden, um beim Ableiten benutzerdefinierter Parameterstrukturen aus dieser Vorlage eine GUID auszuwählen.

3.3.3 Null-Parameter

Die Null-Parameter-Struktur stammt aus der Vorlage Generische Parameter (siehe Abschnitt 3.3.2) und muss ein nicht verwendetes Parameterfeld beschreiben (siehe Tabelle 9). Beim Erstellen oder Aktualisieren der OEM-Parameter-Struktur müssen Implementierungen nicht verwendete Parameterfelder mit der Null-Parameter-Struktur auffüllen. Außerdem sollten Implementierungen beim Erstellen oder Aktualisieren der OEM-Parameterstruktur NULL-Parameter-Strukturen am Ende des Arrays konsolidieren, sodass alle anderen Parameterstrukturen am Anfang der OEM-Parameterstruktur stehen.

Die Unterstützung der Null-Parameter-Struktur ist obligatorisch.

Tabelle 9 NULL-Parameterstruktur

Feldname

Offset

(Byte)

Größe

(Bytes)

 Kommentare
ParametersGuid 0 16 Dieses Feld ist obligatorisch, und in Abschnitt 3.3.3.1 wird der Inhalt definiert.
Reserviert 16 32 Dieses Feld ist obligatorisch, und sein Inhalt ist reserviert.
3.3.3.1 ParameterGuid Field

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-Notation ist {00000000-0000-0000-0000-000000000000}.

3.3.4 Blitzparameter

Die Flash-Parameterstruktur stammt aus der Vorlage Generische Parameter (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 Flash-Parameter-Struktur verwenden, um Zugriffsvorgänge während Lese-/Schreibvorgängen zu optimieren und für die Ausrichtung von Dateisystemstrukturen zu verwenden, die die Formatierung der Medien nicht beeinträchtigen.

Die Unterstützung für die Struktur "Flashparameter" ist optional.

Struktur der Flashparameter in Tabelle 10

Feldname

Offset

(Byte)

Größe

(Bytes)

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

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

3.3.4.1 ParameterGuid-Feld

Das Feld ParametersGuid muss der Definition in der Vorlage Generische Parameter entsprechen (siehe Abschnitt 3.3.2.1).

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

3.3.4.2 EraseBlockSize-Feld

Das Feld EraseBlockSize muss die Größe des Löschblocks des Flashmediums in Bytes beschreiben.

3.3.4.3 PageSize Field

Das PageSize-Feld muss die Größe der Seite des Flashmediums in Byte beschreiben.

3.3.4.4 SpareSectors Field

Im Feld "SpareSektoren" wird die Anzahl der Sektoren beschrieben, die das Flash-Medium für seine internen Sparingvorgänge zur Verfügung hat.

3.3.4.5 RandomAccessTime-Feld

Das Feld RandomAccessTime muss die durchschnittliche zufällige Zugriffszeit des Flashmediums in Nanosekunden beschreiben.

3.3.4.6 ProgrammingTime Field

Das Feld ProgrammingTime soll die durchschnittliche Programmierzeit des Flashmediums in Nanosekunden beschreiben.

3.3.4.7 ReadCycle Field

Das Feld ReadCycle muss die durchschnittliche Lesezykluszeit des Flashmediums in Nanosekunden beschreiben.

3.3.4.8 WriteCycle Field

Das Feld WriteCycle muss die durchschnittliche Schreibzykluszeit in Nanosekunden beschreiben.

3.4 Unterregionen der Haupt- und Sicherungsstartprüfsumme

Die Haupt- und Sicherungsstartprüfsummen enthalten jeweils ein wiederholtes Muster der Vier-Byte-Prüfsumme des Inhalts aller anderen Unterregionen in den jeweiligen Startregionen. Die Prüfsummenberechnung darf die Felder VolumeFlags und PercentInUse im jeweiligen Startsektor nicht enthalten (siehe Abbildung 1). Das wiederholte Muster der Vier-Byte-Prüfsumme füllt den jeweiligen Unterbereich der Startprüfsumme vom Anfang bis zum Ende des Unterbereichs aus.

Vor der Verwendung der Inhalte einer der anderen Unterregionen in den Regionen Main oder Backup Boot müssen Implementierungen ihren Inhalt überprüfen, indem sie ihre jeweilige Startprüfsumme überprüfen.

Während der anfängliche Formatvorgang sowohl die Main- als auch die Sicherungsstartprüfsummen mit dem wiederholten Prüfsummenmuster auffüllt, müssen Implementierungen diese Sektoren aktualisieren, wenn sich der Inhalt der anderen Sektoren in den jeweiligen Startregionen ändert.

Abbildung 1 Berechnung der Startprüfsumme

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 Dateizuordnungstabellenregion

Der FAT-Bereich (File Allocation Table) kann bis zu zwei FATs enthalten, eines in der ersten FAT-Unterregion und ein weiteres in der zweiten FAT-Unterregion. Das Feld NumberOfFats beschreibt, wie viele FATs dieser Bereich enthält. Die gültigen Werte für das Feld NumberOfFats sind 1 und 2. Daher enthält der erste FAT-Unterbereich immer eine FAT. Wenn das NumberOfFats-Feld zwei ist, enthält der zweite FAT-Unterbereich ebenfalls ein FAT.

Das ActiveFat-Feld des VolumeFlags-Felds beschreibt, welches FAT aktiv ist. Nur das Feld VolumeFlags im Hauptstartsektor ist aktuell. Bei implementierungen wird die nicht aktive FAT als veraltet behandelt. Die Verwendung des inaktiven FAT und das Wechseln zwischen FATs ist implementierungsspezifisch.

4.1 Erste und zweite FAT-Unterregionen

Ein FAT muss Clusterketten im Clusterheap beschreiben (siehe Tabelle 11). Eine Clusterkette ist eine Reihe von Clustern, die Platz zum Aufzeichnen der Inhalte von Dateien, Verzeichnissen und anderen Dateisystemstrukturen bietet. Ein FAT stellt eine Clusterkette als eine eng 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

(Byte)

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

.

.

.

.

.

.

.

.

.

.

.

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

Dieses Feld ist obligatorisch, und in Abschnitt 4.1.3 wird der Inhalt definiert.

ClusterCount + 1 darf FFFFFFF6h nie überschreiten.

Hinweis: Der Hauptsektor und der Sicherungsstartsektor enthalten beide das Feld ClusterCount.
ExcessSpace (ClusterCount + 2) * 4 (FatLength * 2BytesPerSectorShift) – ((ClusterCount + 2) * 4)

Dieses Feld ist obligatorisch, und sein Inhalt ist, falls vorhanden, undefiniert.

Hinweis: Der Haupt- und der Sicherungsstartsektor enthalten beide die Felder ClusterCount, FatLength und BytesPerSectorShift.

4.1.1 FatEntry[0] Feld

Das Feld FatEntry[0] muss den Medientyp im ersten Byte (das Byte der niedrigsten Ordnung) beschreiben und FFh in den verbleibenden drei Bytes enthalten.

Der Medientyp (das erste Byte) sollte F8h sein.

4.1.2 FatEntry[1] Feld

Das Feld FatEntry[1] existiert nur aufgrund der historischen Rangfolge und beschreibt nichts interessantes.

Der gültige Wert für dieses Feld ist FFFFFFFFh. Implementierungen müssen dieses Feld mit dem vorgeschriebenen Wert initialisieren und dürfen dieses Feld nicht zu irgendeinem Zweck verwenden. Implementierungen sollten dieses Feld nicht interpretieren und dessen Inhalt über Vorgänge hinweg beibehalten, die umgebende Felder ändern.

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

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

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

  • Zwischen 2 und ClusterCount + 1, einschließlich, der auf die nächste FatEntry in der angegebenen Clusterkette verweist; die angegebene FatEntry darf nicht auf FatEntry verweisen, die ihm in der angegebenen Clusterkette vorangestellt ist.

  • Genau FFFFFFF7h, das den entsprechenden FatEntry-Cluster als "schlecht" markiert

  • Genau FFFFFFFFh, die den entsprechenden FatEntry-Cluster als letzten Cluster einer Clusterkette markiert; Dies ist der einzige gültige Wert für das letzte FatEntry einer bestimmten Clusterkette.

5 Datenregion

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

5.1 Unterregion des Clusterheaps

Die Struktur des Clusterheaps ist sehr einfach (siehe Tabelle 12); Jede aufeinander folgende Reihe von Sektoren beschreibt einen Cluster, wie im Feld SectorsPerClusterShift definiert. Wichtig ist, dass der erste Cluster des Clusterheaps index zwei aufweist, der direkt dem Index von FatEntry[2] entspricht.

In einem exFAT-Volume verwaltet eine Zuordnungsbitbitbit (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 denen ein FAT einen Datensatz des Zuordnungsstatus aller Cluster im Clusterheap verwaltete.

Tabelle 12: Clusterheapstruktur

Feldname

Offset

(Sektor)

Größe

(Sektoren)

 Kommentare
Cluster[2] ClusterHeapOffset 2SektorenPerClusterShift

Dieses Feld ist obligatorisch, und in Abschnitt 5.1.1 wird der Inhalt definiert.

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

.

.

.

.

.

.

.

.

.

.

.

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

Dieses Feld ist obligatorisch, und in Abschnitt 5.1.1 wird der Inhalt definiert.

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 Clusterheap vorhanden sind. Verzeichnisse verfügen über eine 1:n-Beziehung zwischen übergeordnetem und untergeordnetem Element in der Verzeichnisstruktur.

Das Verzeichnis, auf das das Feld FirstClusterOfRootDirectory verweist, ist das Stammverzeichnis der Verzeichnisstruktur. Alle anderen Verzeichnisse stammen in einer singly verknüpften Weise vom Stammverzeichnis ab.

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

Ein oder mehrere Verzeichniseinträge werden zu einem Verzeichniseintragssatz kombiniert, der interessante Elemente beschreibt, z. B. eine Dateisystemstruktur, ein Unterverzeichnis oder eine Datei.

Verzeichnisstruktur in Tabelle 13

Feldname

Offset

(Byte)

Größe

(Byte)

 Kommentare
DirectoryEntry[0] 0 32 Dieses Feld ist obligatorisch, und in Abschnitt 6.1 wird der Inhalt definiert.

.

.

.

.

.

.

.

.

.

.

.

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

Dieses Feld ist obligatorisch, und in Abschnitt 6.1 wird der Inhalt definiert.

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 Bytes.

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

Jedes DirectoryEntry-Feld in diesem Array leitet sich von der Generischen DirectoryEntry-Vorlage ab (siehe Abschnitt 6.2).

6.2 Generic DirectoryEntry Template

Die Vorlage Generic DirectoryEntry stellt die Basisdefinition für Verzeichniseinträge bereit (siehe Tabelle 14). Alle Verzeichniseintragsstrukturen stammen von dieser Vorlage ab, und nur von Microsoft definierte Verzeichniseintragsstrukturen sind gültig (exFAT hat keine Bestimmungen für vom Hersteller definierte Verzeichniseintragsstrukturen, außer wie in Abschnitt 7.8 und Abschnitt 7.9 definiert). Die Möglichkeit, die Generische DirectoryEntry-Vorlage zu interpretieren, ist obligatorisch.

Tabelle 14 Generische Verzeichniseintragsvorlage

Feldname

Offset

(Byte)

Größe

(Byte)

 Kommentare
EntryType 0 1 Dieses Feld ist obligatorisch, und in Abschnitt 6.2.1 wird der Inhalt definiert.
CustomDefined 1 19 Dieses Feld ist obligatorisch, und strukturen, die von dieser Vorlage abgeleitet sind, können den Inhalt definieren.
FirstCluster 20 4 Dieses Feld ist obligatorisch, und in Abschnitt 6.2.2 wird der Inhalt definiert.
DataLength 24 8 Dieses Feld ist obligatorisch, und in Abschnitt 6.2.3 wird der Inhalt definiert.

6.2.1 EntryType Field

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

  • 00h, das ist ein Marker zum Ende des Verzeichnisses, und es gelten die folgenden Bedingungen:

    • Alle anderen Felder im angegebenen DirectoryEntry sind tatsächlich reserviert.

    • Alle nachfolgenden Verzeichniseinträge im angegebenen Verzeichnis sind auch End-of-Directory-Marker

    • Markierungen zum Ende des Verzeichnisses sind nur außerhalb von Verzeichniseintragssätzen gültig.

    • Implementierungen können bei Bedarf Markierungen zum Ende des Verzeichnisses überschreiben

  • Zwischen 01h und 7Fh inklusive, die ein nicht verwendeter Verzeichniseintragsmarker ist und die folgenden Bedingungen gelten:

    • Alle anderen Felder im angegebenen DirectoryEntry sind tatsächlich undefiniert.

    • 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), das den Wert 0 enthält.

  • Zwischen 81h und FFh inklusive, die ein regulärer Verzeichniseintrag ist und die folgenden Bedingungen gelten:

    • Der Inhalt des EntryType-Felds (siehe Tabelle 15) bestimmt das Layout des restlichen Elements 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), das den Wert 1 enthält.

Um Änderungen am InUse-Feld zu verhindern (siehe Abschnitt 6.2.1.4), die fälschlicherweise zu einem Verzeichnisendemarker führen, 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 in Abschnitt 6.2.1.1 wird der Inhalt definiert.
TypeImportance 5 1 Dieses Feld ist obligatorisch, und abschnitt 6.2.1.2 definiert seinen Inhalt.
TypeCategory 6 1 Dieses Feld ist obligatorisch, und in Abschnitt 6.2.1.3 wird der Inhalt definiert.
InUse 7 1 Dieses Feld ist obligatorisch, und in Abschnitt 6.2.1.4 wird der Inhalt definiert.
6.2.1.1 TypeCode Field

Das Feld TypeCode beschreibt teilweise den spezifischen Typ des angegebenen Verzeichniseintrags. Dieses Feld sowie die Felder TypeImportance und TypeCategory (siehe Abschnitt 6.2.1.2 bzw . 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 Field

Das Feld TypeImportance muss die Bedeutung des angegebenen Verzeichniseintrags beschreiben.

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äre und kritische sekundäre Verzeichniseinträge).

  • 1, was bedeutet, dass der angegebene Verzeichniseintrag gutartig ist (siehe Abschnitt 6.3.1.2.2 und Abschnitt 6.4.1.2.2 für gutartige primäre und gutartige sekundäre Verzeichniseinträge)

6.2.1.3 TypeCategory Field

Das Feld TypeCategory muss die Kategorie des angegebenen Verzeichniseintrags beschreiben.

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

  • 0, was bedeutet, dass der angegebene Verzeichniseintrag primär ist (siehe Abschnitt 6.3).

  • 1 bedeutet, dass der angegebene Verzeichniseintrag sekundär ist (siehe Abschnitt 6.4).

6.2.1.4 InUse Field

Das Feld InUse muss beschreiben, 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 es sich bei der angegebenen Struktur tatsächlich um einen nicht verwendeten Verzeichniseintrag handelt.

  • 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 muss den Index des ersten Clusters einer Zuordnung im Cluster heap enthalten, der dem angegebenen Verzeichniseintrag zugeordnet ist.

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

  • Genau 0, was bedeutet, dass keine Clusterzuordnung vorhanden ist

  • Zwischen 2 und ClusterCount + 1, was der Bereich der gültigen Clusterindizes ist

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 Field

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

Der gültige Wertbereich 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 VerzeichnisVorlage

Der erste Verzeichniseintrag in einem Verzeichniseintragssatz muss ein primärer Verzeichniseintrag sein. Alle nachfolgenden Verzeichniseinträge, sofern vorhanden, im Verzeichniseintragssatz sind sekundäre Verzeichniseinträge (siehe Abschnitt 6.4).

Die Möglichkeit, die Vorlage Generisches primäres Verzeichnis Zu interpretieren, ist obligatorisch.

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

Tabelle 16 Generisches primäres VerzeichnisVorlage

Feldname

Offset

(Byte)

Größe

(Byte)

 Kommentare
EntryType 0 1 Dieses Feld ist obligatorisch, und in Abschnitt 6.3.1 wird der Inhalt definiert.
SecondaryCount 1 1 Dieses Feld ist obligatorisch, und in Abschnitt 6.3.2 wird der Inhalt definiert.
SetChecksum 2 2 Dieses Feld ist obligatorisch, und in Abschnitt 6.3.3 wird der Inhalt definiert.
GeneralPrimaryFlags 4 2 Dieses Feld ist obligatorisch, und in Abschnitt 6.3.4 wird der Inhalt definiert.
CustomDefined 6 14 Dieses Feld ist obligatorisch, und strukturen, die von dieser Vorlage abgeleitet sind, definieren den Inhalt.
FirstCluster 20 4 Dieses Feld ist obligatorisch, und in Abschnitt 6.3.5 wird der Inhalt definiert.
DataLength 24 8 Dieses Feld ist obligatorisch, und in Abschnitt 6.3.6 wird der Inhalt definiert.

6.3.1 EntryType Field

Das Feld EntryType muss der Definition entsprechen, die in der Vorlage Generic DirectoryEntry bereitgestellt wird (siehe Abschnitt 6.2.1).

6.3.1.1 TypeCode Field

Das Feld TypeCode muss der Definition entsprechen, die in der Generischen DirectoryEntry-Vorlage bereitgestellt wird (siehe Abschnitt 6.2.1.1).

6.3.1.2 TypeImportance Field

Das Feld TypeImportance muss der Definition entsprechen, die in der Vorlage Generic DirectoryEntry bereitgestellt wird (siehe Abschnitt 6.2.1.2).

6.3.1.2.1 Wichtige Primäre Verzeichniseinträge

Wichtige primäre Verzeichniseinträ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ärer Verzeichniseinträge korreliert mit der hauptrefat-Revisionsnummer. Implementierungen müssen alle wichtigen primären Verzeichniseinträge unterstützen und nur die von dieser Spezifikation definierten strukturen für kritische primäre Verzeichnisse aufzeichnen.

6.3.1.2.2 Gutartige Primäre Verzeichniseinträge

Gutartige primäre Verzeichniseinträ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 von gutartigen primären Verzeichniseinträgen korreliert mit der nebensächlichen exFAT-Revisionsnummer. Die Unterstützung für jeden gutartigen primären Verzeichniseintrag, den diese Spezifikation oder eine nachfolgende Spezifikation definiert, ist optional. Ein nicht erkannter gutartiger primärer Verzeichniseintrag rendert den gesamten Verzeichniseintragssatz als nicht erkannt (über die Definition der entsprechenden Verzeichniseintragsvorlagen hinaus).

6.3.1.3 TypeCategory Field

Das Feld TypeCategory muss der Definition entsprechen, die in der Vorlage Generic DirectoryEntry bereitgestellt wird (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 Field

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

6.3.2 SecondaryCount Field

Das Feld SecondaryCount muss die Anzahl der sekundären Verzeichniseinträge beschreiben, die unmittelbar auf den angegebenen Primären Verzeichniseintrag folgen. Diese sekundären Verzeichniseinträge bilden zusammen mit dem angegebenen primären Verzeichniseintrag den Verzeichniseintragssatz.

Der gültige Wertebereich für dieses Feld muss sein:

  • Mindestens 0. Dies bedeutet, dass dieser primäre Verzeichniseintrag der einzige Eintrag im Verzeichniseintragssatz ist.

  • Höchstens 255, d. h. die nächsten 255 Verzeichniseinträge und dieser primäre Verzeichniseintrag umfassen den Verzeichniseintragssatz.

Wichtige primäre Verzeichniseintragsstrukturen, 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 muss die Prüfsumme aller Verzeichniseinträge im angegebenen Verzeichniseintragssatz enthalten. Die Prüfsumme schließt dieses Feld jedoch aus (siehe Abbildung 2). Implementierungen müssen überprüfen, ob der Inhalt dieses Felds gültig ist, bevor ein anderer Verzeichniseintrag im angegebenen Verzeichniseintragssatz verwendet wird.

Wichtige primäre Verzeichniseintragsstrukturen, 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äre Verzeichniseintragsstrukturen, die von dieser Vorlage abgeleitet werden, können dieses Feld neu definieren.

Tabelle 17 Generische GeneralPrimaryFlags-Feldstruktur

Feldname

Offset

(Bit)

Größe

(Bits)

 Kommentare
AllocationPossible 0 1 Dieses Feld ist obligatorisch, und in Abschnitt 6.3.4.1 wird der Inhalt definiert.
NoFatChain 1 1 Dieses Feld ist obligatorisch, und in Abschnitt 6.3.4.2 wird der Inhalt definiert.
CustomDefined 2 14 Dieses Feld ist obligatorisch, und strukturen, die von dieser Vorlage abgeleitet sind, können dieses Feld definieren.
6.3.4.1 AllocationPossible Field

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

Gültige 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 undefiniert sind (Strukturen, die von dieser Vorlage abgeleitet werden, können diese Felder neu definieren).

  • 1, d. h. eine zugeordnete Zuordnung von Clustern ist möglich, und die Felder FirstCluster und DataLength sind wie definiert.

6.3.4.2 NoFatChain-Feld

Das Feld NoFatChain muss angeben, ob die aktive FAT die Clusterkette der angegebenen Zuordnung beschreibt oder nicht.

Gültige Werte für dieses Feld sind:

  • 0, d. h. die entsprechenden FAT-Einträge für die Clusterkette der Zuteilung sind gültig, und die Implementierungen müssen sie interpretieren; Wenn das Feld AllocationPossible den Wert 0 enthält oder das Feld AllocationPossible den Wert 1 und das Feld FirstCluster den Wert 0 enthält, ist der einzige gültige Wert dieses Felds 0.

  • 1, d. h. die zugeordnete Zuordnung ist eine zusammenhängende Reihe von Clustern; die entsprechenden FAT-Einträge für die Cluster ungültig sind, und implementierungen 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 wichtige primäre Verzeichniseintragsstrukturen, 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 (siehe Abschnitt 6.2.2) bereitgestellt wird.

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

Wichtige primäre Verzeichniseintragsstrukturen, die von dieser Vorlage abgeleitet werden, können die Felder FirstCluster und DataLength neu definieren. Andere Von dieser Vorlage abgeleitete Strukturen können die Felder FirstCluster und DataLength nur neu definieren, wenn das Feld AllocationPossible den Wert 0 enthält.

6.3.6 DataLength-Feld

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

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

Wichtige primäre Verzeichniseintragsstrukturen, die von dieser Vorlage abgeleitet werden, können die Felder FirstCluster und DataLength neu definieren. Andere Von dieser Vorlage abgeleitete Strukturen können die Felder FirstCluster und DataLength nur neu definieren, wenn das Feld AllocationPossible den Wert 0 enthält.

6.4 Generische sekundäre VerzeichnisVorlage

Der zentrale Zweck sekundärer Verzeichniseinträge besteht darin, zusätzliche Informationen zu einem Verzeichniseintragssatz bereitzustellen. Die Möglichkeit, die Vorlage Generisches sekundäres Verzeichnis Zu interpretieren, ist obligatorisch.

Die Definition sowohl kritischer als auch gutartiger sekundärer Verzeichniseinträge korreliert mit der nebengeordneten exFAT-Revisionsnummer. Die Unterstützung für alle kritischen oder harmlosen sekundären Verzeichniseinträge, die diese Spezifikation oder nachfolgende Spezifikationen definiert, 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 Generische sekundäre VerzeichnisVorlage

Feldname

Offset

(Byte)

Größe

(Byte)

 Kommentare
EntryType 0 1 Dieses Feld ist obligatorisch, und abschnitt 6.4.1 definiert seinen Inhalt.
GeneralSecondaryFlags 1 1 Dieses Feld ist obligatorisch, und in Abschnitt 6.4.2 wird der Inhalt definiert.
CustomDefined 2 18 Dieses Feld ist obligatorisch, und von dieser Vorlage abgeleitete Strukturen definieren den Inhalt.
FirstCluster 20 4 Dieses Feld ist obligatorisch, und in Abschnitt 6.4.3 wird der Inhalt definiert.
DataLength 24 8 Dieses Feld ist obligatorisch, und in Abschnitt 6.4.4 wird der Inhalt definiert.

6.4.1 EntryType Field

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

6.4.1.1 TypeCode Field

Das Feld TypeCode muss der Definition entsprechen, die in der Vorlage Generic DirectoryEntry bereitgestellt wird (siehe Abschnitt 6.2.1.1).

6.4.1.2 TypeImportance Field

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

6.4.1.2.1 Wichtige sekundäre Verzeichniseinträge

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

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

6.4.1.2.2 Gutartige sekundäre Verzeichniseinträge

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

Implementierungen ignorieren möglicherweise jeden harmlosen sekundären Eintrag, den sie nicht erkennt.

6.4.1.3 TypeCategory-Feld

Das Feld TypeCategory muss der Definition entsprechen, die in der Vorlage Generic DirectoryEntry bereitgestellt wird (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 Field

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

6.4.2 GeneralSecondaryFlags Field

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

Tabelle 19 Generische GeneralSecondaryFlags-Feldstruktur

Feldname

Offset

(Bit)

Größe

(Bits)

 Kommentare
AllocationPossible 0 1 Dieses Feld ist obligatorisch, und in Abschnitt 6.4.2.1 wird der Inhalt definiert.
NoFatChain 1 1 Dieses Feld ist obligatorisch, und in Abschnitt 6.4.2.2 wird der Inhalt definiert.
CustomDefined 2 6 Dieses Feld ist obligatorisch, und strukturen, die von dieser Vorlage abgeleitet sind, können dieses Feld definieren.
6.4.2.1 AllocationPossible Field

Das Feld AllocationPossible muss dieselbe Definition wie das feld mit dem gleichen Namen in der Vorlage Generisches primäres Verzeichnis Aufweisen aufweisen (siehe Abschnitt 6.3.4.1).

6.4.2.2 NoFatChain-Feld

Das Feld "NoFatChain" muss dieselbe Definition wie das gleichnamige Feld in der Vorlage Generisches primäres Verzeichnis (siehe Abschnitt 6.3.4.2) aufweisen.

6.4.3 FirstCluster Field

Das Feld FirstCluster muss der Definition entsprechen, die in der Vorlage Generic DirectoryEntry (siehe Abschnitt 6.2.2) bereitgestellt wird.

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

6.4.4 DataLength Field

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

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

7 Verzeichniseintragsdefinitionen

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

7.1 Zuordnungs-Bitmap-Verzeichniseintrag

Im exFAT-Dateisystem beschreibt ein FAT nicht den Zuordnungsstatus von Clustern. eine Zuordnungsbit tut dies. Zuordnungsbits sind im Clusterheap vorhanden (siehe Abschnitt 7.1.5) und verfügen über entsprechende wichtige primäre Verzeichniseinträge im Stammverzeichnis (siehe Tabelle 20).

Das Feld NumberOfFats bestimmt die Anzahl gültiger Zuordnungsbitbit-Verzeichniseinträge im Stammverzeichnis. Wenn das Feld NumberOfFats den Wert 1 enthält, ist die einzige gültige Anzahl von Zuordnungs-Bitmap-Verzeichniseinträgen 1. Darüber hinaus ist der einzige Zuordnungsbitbit-Verzeichniseintrag nur gültig, wenn er die Erste Zuordnungsbit beschreibt (siehe Abschnitt 7.1.2.1). Wenn das Feld NumberOfFats den Wert 2 enthält, ist die einzige gültige Anzahl von Allocation Bitmap-Verzeichniseinträgen 2. Darüber hinaus sind die beiden Zuordnungsbitbit-Verzeichniseinträge nur gültig, wenn einer die Erste Zuordnungsbit und der andere die zweite Zuordnungsbit beschreibt.

Table 20 Allocation Bitmap DirectoryEntry Structure

Feldname

Offset

(Byte)

Größe

(Byte)

 Kommentare
EntryType 0 1 Dieses Feld ist obligatorisch, und in Abschnitt 7.1.1 wird der Inhalt definiert.
BitmapFlags 1 1 Dieses Feld ist obligatorisch, und in Abschnitt 7.1.2 wird der Inhalt definiert.
Reserviert 2 18 Dieses Feld ist obligatorisch, und sein Inhalt ist reserviert.
FirstCluster 20 4 Dieses Feld ist obligatorisch, und in Abschnitt 7.1.3 wird der Inhalt definiert.
DataLength 24 8 Dieses Feld ist obligatorisch, und in Abschnitt 7.1.4 wird der Inhalt definiert.

7.1.1 EntryType Field

Das Feld EntryType muss der Definition entsprechen, die in der Vorlage Generisches primäres Verzeichnis (siehe Abschnitt 6.3.1) bereitgestellt wird.

7.1.1.1 TypeCode-Feld

Das Feld TypeCode muss der Definition in der Vorlage Generisches primäres Verzeichnis entsprechen (siehe Abschnitt 6.3.1.1).

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

7.1.1.2 TypeImportance Field

Das Feld TypeImportance muss der Definition in der Vorlage Generisches primäres Verzeichnis Entsprechen (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 TypeCategory Field

Das Feld TypeCategory muss der Definition in der Vorlage Generisches primäres Verzeichnis Entsprechen (siehe Abschnitt 6.3.1.3).

7.1.1.4 InUse Field

Das Feld InUse muss der Definition in der Vorlage Generisches primäres Verzeichnis Entsprechen (siehe Abschnitt 6.3.1.4).

7.1.2 BitmapFlags-Feld

Das Feld BitmapFlags 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 in Abschnitt 7.1.2.1 wird der Inhalt definiert.
Reserviert 1 7 Dieses Feld ist obligatorisch, und sein Inhalt ist reserviert.
7.1.2.1 BitmapIdentifier Field

Das BitmapIdentifier-Feld muss angeben, welche Zuordnungs-Bitmap der angegebene Verzeichniseintrag beschreibt. Implementierungen verwenden die Bitmap "Erste Zuordnung" in Verbindung mit dem ersten FAT und die zweite Zuordnungsbitbit in Verbindung mit dem zweiten FAT. Das Feld ActiveFat beschreibt, welche FAT- und Zuordnungsbit aktiv sind.

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

  • 0, d. h. der angegebene Verzeichniseintrag beschreibt die Bitmap "First Allocation"

  • 1, was bedeutet, dass der angegebene Verzeichniseintrag die zweite Zuordnungsbitbit beschreibt und nur möglich ist, wenn NumberOfFats den Wert 2 enthält.

7.1.3 FirstCluster Field

Das Feld FirstCluster muss der Definition in der Vorlage Generisches primäres Verzeichnis Entsprechen (siehe Abschnitt 6.3.5).

Dieses Feld enthält den Index des ersten Clusters der Clusterkette, wie im FAT beschrieben, der die Zuordnungsbitbitbit hostet.

7.1.4 DataLength Field

Das Feld DataCluster muss der Definition in der Vorlage Generisches primäres Verzeichnis Entsprechen (siehe Abschnitt 6.3.6).

7.1.5 Zuordnungsbitbit

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

Eine Zuordnungs-Bitmap stellt Cluster vom niedrigsten bis zum höchsten Index dar (siehe Tabelle 22). Aus historischen Gründen weist der erste Cluster den Index 2 auf. Hinweis: Das erste Bit in der Bitmap ist das Bit der niedrigsten Reihenfolge des ersten Byte.

Bitmapstruktur der Zuordnung in Tabelle 22

Feldname

Offset

(Bit)

Größe

(Bits)

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

.

.

.

.

.

.

.

.

.

.

.

.
BitmapEntry[ClusterCount+1] ClusterCount – 1 1

Dieses Feld ist obligatorisch, und in Abschnitt 7.1.5.1 wird der Inhalt definiert.

Hinweis: Der Haupt- und der Sicherungsstartsektor enthalten beide das Feld ClusterCount.
Reserviert ClusterCount (DataLength * 8) – ClusterCount

Dieses Feld ist obligatorisch, und sein Inhalt ist reserviert, falls vorhanden.

Hinweis: Der Haupt- und der Sicherungsstartsektor enthalten beide das Feld ClusterCount.
7.1.5.1 BitmapEntry[2] ... BitmapEntry[ClusterCount+1] Felder

Jedes BitmapEntry-Feld in diesem Array stellt einen Cluster im Clusterheap dar. BitmapEntry[2] stellt den ersten Cluster im Clusterheap dar, und BitmapEntry[ClusterCount+1] stellt den letzten Cluster im Clusterheap dar.

Die gültigen Werte für diese Felder müssen sein:

  • 0, der den entsprechenden Cluster als für die Zuordnung verfügbar beschreibt

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

7.2 Up-Case-Tabellenverzeichniseintrag

Die Großbuchstabentabelle definiert die Konvertierung von Klein- in Großbuchstaben. Dies ist wichtig, da der Dateiname-Verzeichniseintrag (siehe Abschnitt 7.7) Unicode-Zeichen verwendet und das exFAT-Dateisystem die Groß- und Kleinschreibung nicht beachtet. Die Up-Case-Tabelle ist im Clusterheap vorhanden (siehe Abschnitt 7.2.5) und verfügt über einen entsprechenden kritischen primären Verzeichniseintrag im Stammverzeichnis (siehe Tabelle 23). Die gültige Anzahl der Einträge im Up-Case-Tabellenverzeichnis ist 1.

Aufgrund der Beziehung zwischen der Up-Case-Tabelle und dateinamen sollten Implementierungen die Up-Case-Tabelle nicht ändern, außer als Ergebnis von Formatvorgängen.

Table 23 Up-Case-TabellenverzeichnisVerzeichnisStruktur

Feldname

Offset

(Byte)

Größe

(Byte)

 Kommentare
EntryType 0 1 Dieses Feld ist obligatorisch, und in Abschnitt 7.2.1 wird der Inhalt definiert.
Reserved1 1 3 Dieses Feld ist obligatorisch, und sein Inhalt ist reserviert.
TableChecksum 4 4 Dieses Feld ist obligatorisch, und in Abschnitt 7.2.2 wird der Inhalt definiert.
Reserved2 8 12 Dieses Feld ist obligatorisch, und sein Inhalt ist reserviert.
FirstCluster 20 4 Dieses Feld ist obligatorisch, und in Abschnitt 7.2.3 wird der Inhalt definiert.
DataLength 24 8 Dieses Feld ist obligatorisch, und in Abschnitt 7.2.4 wird der Inhalt definiert.

7.2.1 EntryType Field

Das Feld EntryType muss der Definition in der Vorlage Generisches primäres Verzeichnis Entsprechen (siehe Abschnitt 6.3.1).

7.2.1.1 TypeCode Field

Das Feld TypeCode muss der Definition in der Vorlage Generisches primäres Verzeichnis Entsprechen (siehe Abschnitt 6.3.1.1).

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

7.2.1.2 TypeImportance Field

Das Feld TypeImportance muss der Definition in der Vorlage Generisches primäres Verzeichnis Entsprechen (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 muss der Definition in der Vorlage Generisches primäres Verzeichnis Entsprechen (siehe Abschnitt 6.3.1.3).

7.2.1.4 InUse-Feld

Das Feld InUse muss der Definition in der Vorlage Generisches primäres Verzeichnis Entsprechen (siehe Abschnitt 6.3.1.4).

7.2.2 TableChecksum Field

Das Feld TableChecksum enthält die Prüfsumme der Up-Case-Tabelle (die in den Feldern FirstCluster und DataLength beschrieben wird). Implementierungen müssen ü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 in der Vorlage Generisches primäres Verzeichnis Entsprechen (siehe Abschnitt 6.3.5).

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

7.2.4 DataLength Field

Das Feld DataCluster muss der Definition in der Vorlage Generisches primäres Verzeichnis Entsprechen (siehe Abschnitt 6.3.6).

7.2.5 Up-Case-Tabelle

Eine Tabelle mit up-case ist eine Reihe von Unicode-Zeichenzuordnungen. Eine Zeichenzuordnung besteht aus einem 2-Byte-Feld, wobei der Index des Felds in der Tabelle mit dem Groß-/Kleinschreibungsfall das unicode-Zeichen darstellt, das groß geschrieben werden soll, und dem 2-Byte-Feld, das das Unicode-Zeichen mit up-cased darstellt.

Die ersten 128 Unicode-Zeichen weisen obligatorische Zuordnungen auf (siehe Tabelle 24). Eine Tabelle mit up-case, die über eine andere Zeichenzuordnung für eines der ersten 128 Unicode-Zeichen verfügt, ist ungültig.

Implementierungen, die nur Zeichen aus dem obligatorischen Zuordnungsbereich unterstützen, ignorieren möglicherweise die Zuordnungen der restlichen Tabelle mit up-case. Diese Implementierungen dürfen beim Erstellen oder Umbenennen von Dateien nur Zeichen aus dem obligatorischen Zuordnungsbereich verwenden (über den Verzeichniseintrag Dateiname, siehe Abschnitt 7.7). Beim Up-Casing vorhandener Dateinamen dürfen solche Implementierungen keine Großbuchstaben aus dem nicht obligatorischen Zuordnungsbereich übernehmen, sondern sie im sich ergebenden up-cased-Dateinamen intakt lassen (dies ist ein teilweises Up-Casing). Beim Vergleich von Dateinamen dürfen solche Implementierungen Dateinamen, die sich vom Vergleichsnamen unterscheiden, nur durch Unicode-Zeichen aus dem nicht obligatorischen Zuordnungsbereich als gleichwertig behandeln. Obwohl solche Dateinamen nur potenziell gleichwertig sind, können solche Implementierungen nicht sicherstellen, dass der vollständig aufgesetzte Dateiname nicht mit dem vergleichsbezogenen Namen kollidiert.

Tabelle 24 Obligatorische erste 128 Up-Case-Tabelleneinträge

Tabellenindex + 0 + 1 + 2 + 3 + 4 + 5 + 6 + 7
0000h 0000h 0001h 0002h 0003h 0004 Stunden 0005h 0006h 0007h
0008h 0008h 0009h 000Ah 000 Bh 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äts-Up-Case-Zuordnungen sind fett formatiert)

Beim Formatieren eines Volumes können Implementierungen mithilfe der Identitätszuordnungskomprimierung eine Up-Case-Tabelle in einem komprimierten Format generieren, da ein großer Teil des Unicode-Zeichenraums kein Konzept der Groß-/Kleinschreibung hat (d. h. die Zeichen "Kleinbuchstaben" und "Großbuchstaben" sind gleichwertig). Implementierungen komprimieren eine Tabelle mit up-case, indem sie eine Reihe von Identitätszuordnungen mit dem Wert FFFFh gefolgt von der Anzahl der Identitätszuordnungen darstellen.

Beispielsweise kann eine Implementierung die ersten 100 (64h)-Zeichenzuordnungen mit den folgenden acht Einträgen einer komprimierten Tabelle mit up-case 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) werden den Zeichen 0041h bis 0043h zugeordnet.

Die Möglichkeit, beim Formatieren eines Volumes eine komprimierte Tabelle mit up-case bereitzustellen, ist optional. Die Möglichkeit, sowohl eine unkomprimierte als auch eine komprimierte Tabelle mit up-case zu interpretieren, ist jedoch obligatorisch. Der Wert des TableChecksum-Felds entspricht immer der Existenz der Up-Case-Tabelle auf dem Volume, die entweder im komprimierten oder nicht komprimierten Format vorliegen kann.

Beim Formatieren eines Volumes sollten Implementierungen die empfohlene Up-Case-Tabelle in komprimiertem Format aufzeichnen (siehe Tabelle 25), für die der Wert des TableChecksum-Felds E619D30Dh ist.

Wenn eine Implementierung eine eigene Up-Case-Tabelle definiert, entweder komprimiert oder unkomprimiert, muss diese Tabelle den gesamten Unicode-Zeichenbereich abdecken (von Zeichencodes 0000h bis einschließlich FFFFh).