exFAT-Dateisystemspezifikation

  • Artikel
  • 96 Minuten Lesedauer

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. Behalten Sie die Einfachheit von FAT-basierten Dateisystemen bei.

    Zwei der Stärken der FAT-basierten Dateisysteme sind ihre relative Einfachheit und Einfache Implementierung. Im Geiste seiner Vorgänger sollte die Implementierung von exFAT relativ einfach und einfach zu implementieren sein.

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

    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 Cluster so groß wie 32 MB, wodurch sehr große Speichergeräte effektiv aktiviert werden.

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

    Das exFAT-Dateisystem integriert die Erweiterbarkeit in das Design, sodass das Dateisystem mit Innovationen im Speicher und änderungen der Nutzung schritthalten kann.

1.2 Spezifische Terminologie

Im Rahmen dieser Spezifikation tragen bestimmte Begriffe (siehe Tabelle 1) spezifische Bedeutung für das Design und die Implementierung des exFAT-Dateisystems.

Tabelle 1 Definition von Begriffen, die sehr spezifische Bedeutung tragen

Begriff Definition
Muss Diese Spezifikation verwendet den Begriff "shall", um ein Verhalten zu beschreiben, das obligatorisch ist.
Optional Diese Spezifikation verwendet den Begriff "sollte", um ein Verhalten zu beschreiben, das es dringend empfiehlt, aber nicht obligatorisch.
May Diese Spezifikation verwendet den Begriff "may", um ein Verhalten zu beschreiben, das optional ist.
Obligatorisch. Dieser Begriff beschreibt ein Feld oder eine Struktur, das eine Implementierung ändert und wie diese Spezifikation beschreibt.
Optional Dieser Begriff beschreibt ein Feld oder eine Struktur, die eine Implementierung unterstützen kann oder nicht. Wenn eine Implementierung ein bestimmtes optionales Feld oder eine bestimmte Struktur unterstützt, ändert sie das Feld oder die Struktur, wie diese Spezifikation beschreibt.
Nicht definiert Dieser Begriff beschreibt Feld- oder Strukturinhalte, die eine Implementierung ggf. ändern kann (d. h. klar auf Null, wenn umgebende Felder oder Strukturen festgelegt werden) und darf nicht interpretiert werden, um eine bestimmte Bedeutung zu enthalten.
Reserviert

Dieser Begriff beschreibt Feld- oder Strukturinhalte, die implementierungen:

  1. Initialisieren sie auf Null und sollten für keinen Zweck verwendet werden.

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

  3. Behält alle Vorgänge bei, die umgebende Felder oder Strukturen ändern

1.3 Volltext allgemeiner Akronyme

Diese Spezifikation verwendet Akronymen 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
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 Transaktionssicher 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 Spezifikationsnotizen sind anders.

  1. Nicht signiert

  2. Verwenden Sie dezimale Notation, um Werte zu beschreiben, sofern nicht anders angegeben; Diese Spezifikation verwendet den Buchstaben "h" nach der Fixierung, um hexadezimale Zahlen zu kennzeichnen und GUIDs in geschweifte Geschweifte Klammern einzuschließen.

  3. Sind im Klein-End-Format

  4. Kein Null-Endzeichen für Zeichenfolgen erforderlich

1.5 Windows CE und TexFAT

TexFAT ist eine Erweiterung für exFAT, die transaktionssichere operative Semantik über dem Basisdateisystem hinzufügt. TexFAT wird von Windows CE verwendet. TexFAT erfordert die Verwendung der beiden FATs und Zuordnungs bitmaps 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 Datenplätze, die zum Speichern und Abrufen von Benutzerdaten erforderlich sind. Alle exFAT-Volumes enthalten vier Regionen (siehe Tabelle 3).

Tabelle 3 Volumenstruktur

Unterbereichsname

Offset

(Sektor)

Größe

(Sektoren)

 Kommentare
Hauptstartbereich
Hauptstartsektor 0 1 Dieser Unterbereich ist obligatorisch und Abschnitt 3.1 definiert seinen Inhalt.
Hauptbereich erweiterter Start 1 8 Dieser Teilbereich ist obligatorisch und Abschnitt 3.2) definiert seinen Inhalt.
Haupt-OEM-Parameter 9 1 Dieser Teilbereich ist obligatorisch und Abschnitt 3.3 definiert seinen Inhalt.
Haupt reserviert 10 1 Diese Unterregion ist obligatorisch und ihre Inhalte sind reserviert.
Hauptstartcheckum 11 1 Dieser Teilbereich ist obligatorisch und Abschnitt 3.4 definiert seinen Inhalt.
Sicherungsstartbereich
Sicherungsstartsektor 12 1 Dieser Teilbereich ist obligatorisch und Abschnitt 3.1 definiert seinen Inhalt.
Sichern erweiterter Startsektoren 13 8 Dieser Teilbereich ist obligatorisch und Abschnitt 3.2 definiert seinen Inhalt.
Sicherungs-OEM-Parameter 21 1 Dieser Teilbereich ist obligatorisch und Abschnitt 3.3 definiert seinen Inhalt.
Sicherung reserviert 22 1 Diese Unterregion ist obligatorisch und ihre Inhalte sind reserviert.
Sicherungsstartcheckum 23 1 Dieser Teilbereich ist obligatorisch und Abschnitt 3.4 definiert seinen Inhalt.
FAT-Region
FAT-Ausrichtung 24 FatOffset – 24

Diese Unterregion ist obligatorisch und ihre Inhalte, falls vorhanden, nicht definiert.

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

Dieser Teilbereich ist obligatorisch und Abschnitt 4.1 definiert seinen Inhalt.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten sowohl die Felder FatOffset als auch FatLength.
Zweite FETT FatOffset + FatLength FatLength * (NumberOfFats – 1)

Dieser Teilbereich ist obligatorisch und Abschnitt 4.1 definiert seinen Inhalt, falls vorhanden.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten sowohl die Felder FatOffset, FatLength und NumberOfFats. Das Feld "NumberOfFats" kann nur Werte 1 und 2 enthalten.
Datenbereich
Cluster-Heap-Ausrichtung FatOffset + FatLength * NumberOfFats ClusterHeapOffset – (FatOffset + FatLength * NumberOfFats)

Diese Unterregion ist obligatorisch und ihre Inhalte, falls vorhanden, 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

Dieser Teilbereich ist obligatorisch und Abschnitt 5.1 definiert seinen Inhalt.

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

Diese Unterregion ist obligatorisch und ihre Inhalte, falls vorhanden, 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 Startbandanweisungen, Identifizierung von Informationen und Dateisystemparametern, um eine Implementierung zu ermöglichen, folgendes auszuführen:

  1. Startband ein Computersystem aus einem ExFAT-Volume.

  2. Identifizieren Sie das Dateisystem auf dem Volume als exFAT.

  3. Entdecken Sie den Speicherort der exFAT-Dateisystemstrukturen.

Der Sicherungsstartbereich ist eine Sicherung des Hauptstartbereichs. Es unterstützt die Wiederherstellung des exFAT-Volumes im Fall des Hauptstartbereichs in einem inkonsistenten Zustand. Außer unter seltenen Umständen, z. B. das Aktualisieren von Startbandanweisungen, sollten Implementierungen den Inhalt des Sicherungsstartbereichs nicht ändern.

3.1 Haupt- und Sicherungsstartsektor-Unterbereiche

Der Hauptstartsektor enthält Code für das Startband von einem ExFAT-Volume und grundlegenden ExFAT-Parametern, die die Volumenstruktur beschreiben (siehe Tabelle 4). BIOS, MBR oder andere Boot-Strapping-Agents können diesen Sektor überprüfen und alle darin enthaltenen Boot-Strapping-Anweisungen laden und ausführen.

Der Sicherungsstartsektor ist eine Sicherung des Hauptstartsektors und verfügt über dieselbe Struktur (siehe Tabelle 4). Der Sicherungsstartsektor kann die Wiederherstellungsvorgänge unterstützen; Die Implementierungen behandeln jedoch den Inhalt der Felder VolumeFlags und PercentInUse als veraltet.

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

Während der anfängliche Formatvorgang den Inhalt sowohl der Haupt- als auch der Sicherungsstartsektor initialisiert, können Implementierungen diese Sektoren aktualisieren (und ihre jeweilige Startchecksumme auch bei Bedarf aktualisieren). Implementierungen können jedoch entweder die Felder VolumeFlags oder PercentInUse aktualisieren, ohne ihre jeweilige Startchecksumme zu aktualisieren (die Prüfsumme schließt diese beiden Felder speziell 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.
FileSystemName 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.
SektorenPerClusterShift 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.
PercentInUse 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.
Exzessspace 512 2BytesPerSectorShift – 512

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

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

3.1.1 JumpBoot Field

Das JumpBoot-Feld enthält die Sprunganweisung für CPUs, die bei ausführung "Springen" die CPU zum Ausführen der Startbandanweisungen im BootCode-Feld verwendet.

Der gültige Wert für dieses Feld ist (in Reihenfolge des Byte mit niedriger Reihenfolge auf Hochreihenfolge) EBh 76h 90h.

3.1.2 FileSystemName Field

Das Feld "FileSystemName" enthält den Namen des Dateisystems auf dem Volume.

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

3.1.3 MustBeZero Field

Das Feld "MustBeZero" entspricht direkt dem Bereich von Bytes, die der verpackte BIOS-Parameterblock verwendet, für FAT12/16/32-Volumes.

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

3.1.4 PartitionOffset Field

Das Feld "PartitionOffset" beschreibt den medienrelativen Sektorversatz der Partition, die das angegebene exFAT-Volume hostt. Dieses Feld unterstützt das Startband aus dem Volume mithilfe erweiterter INT 13h auf persönlichen Computern.

Alle möglichen Werte für dieses Feld sind gültig; Der Wert 0 gibt jedoch an, dass Implementierungen dieses Felds ignoriert werden.

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:

  • Mindestens2 20/2BytesPerSectorShift, wodurch sichergestellt wird, dass das kleinste Volumen nicht kleiner als 1 MB ist.

  • Am meisten 264- 1 kann der größte Wert dieses Felds beschreiben.

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

3.1.6 FatOffset Field

Das FatOffset-Feld beschreibt den Volumen-relativen Sektorversatz des ersten FAT. In diesem Feld können Implementierungen das erste FAT auf die Merkmale des zugrunde liegenden Speichermediums ausrichten.

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

  • Mindestens 24, die für die Bereiche Hauptstart und Sicherungsstartbereiche verwendet werden

  • Am meisten ClusterHeapOffset - (FatLength * NumberOfFats), das die Cluster-Heap verwendet.

3.1.7 FatLength Field

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

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

  • Mindestens (ClusterCount + 2) *2 2/ 2BytesPerSectorShiftauf die nächste ganze Zahl gerundet, wodurch sichergestellt wird, dass jede FAT ausreichend Speicherplatz für die Beschreibung aller Cluster im Cluster-Heap hat

  • Am meisten (ClusterHeapOffset - FatOffset) / NumberOfFats wird auf die nächste ganze Zahl abgerundet, wodurch sichergestellt wird, dass die FATs vor dem Cluster-Heap vorhanden sind.

Dieses Feld kann einen Wert enthalten, der über seine untere Grenze (wie oben beschrieben) verfügt, 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, nicht definiert sind.

3.1.8 ClusterHeapOffset Field

Das Feld "ClusterHeapOffset" beschreibt den Volumen-relativen Sektorversatz des Cluster-Heaps. In 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 vorhergehenden Regionen zu berücksichtigen

  • Am meisten 232-1 oder VolumeLength - (ClusterCount * 2SectorsPerClusterShift), je nachdem, welche Berechnung kleiner ist

3.1.9 ClusterCount Field

Das ClusterCount-Feld beschreibt die Anzahl von Clustern, die der Cluster-Heap enthält.

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

  • (VolumeLength - ClusterHeapOffset) / 2SectorsPerClusterShiftwird auf die nächste ganze Zahl abgerundet, was genau die Anzahl der Cluster ist, die zwischen dem Anfang des Cluster-Heaps und dem Ende des Volumens passen können.

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

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

3.1.10 FirstClusterOfRootDirectory Field

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 schlechten Cluster zu platzieren, nachdem die Cluster die Zuordnungs-Bitmap und die Up-Case-Tabelle verwendet haben.

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

  • Mindestens 2, der Index des ersten Clusters im Cluster-Heap

  • Am meisten ClusterCount + 1 ist der Index des letzten Clusters im Cluster-Heap

3.1.11 VolumeSerialNumber Field

Das Feld "VolumeSerialNumber" enthält eine eindeutige Seriennummer. Dadurch werden Implementierungen unterstützt, um zwischen verschiedenen exFAT-Volumes zu unterscheiden. 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, um eine Seriennummer zu bilden, ist implementierungsspezifisch.

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

3.1.12 FileSystemRevision Field

Das Feld "FileSystemRevision" beschreibt die Haupt- und Nebenrevisionszahlen der exFAT-Strukturen auf dem angegebenen Volumen.

Das Byte mit hoher Reihenfolge ist die Hauptversionsnummer und das Byte mit niedriger Reihenfolge ist die Nebenversionsnummer. 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 FileSystemRevision-Feld die Überarbeitungsnummer 1.05. Ebenso enthält das Hochreihenfolgen-Byte den Wert 0Ah und wenn 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 Hochreihenfolgen-Byte

  • Am meisten 99 für das Byte mit niedriger Reihenfolge und 99 für das Hochreihenfolgen-Byte

Die Überarbeitungsnummer von exFAT, die diese Spezifikation beschreibt, ist 1.00. Implementierungen dieser Spezifikation sollten ein exFAT-Volume mit der Hauptversionsnummer 1 bereitstellen und keine exFAT-Volumen mit einer anderen großen Überarbeitungsnummer bereitstellen. Die Implementierungen werden die nebenrevisionsnummer berücksichtigen und keine Vorgänge ausführen oder Dateisystemstrukturen erstellen, die nicht in der entsprechenden Spezifikation der angegebenen Nebenversionsnummer beschrieben sind.

3.1.13 VolumeFlags Field

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

Implementierungen umfassen dieses Feld nicht, wenn sie ihr jeweiliges Hauptstart- oder Sicherungsstartbereichscheckum berechnen. Bei Bezug auf den Sicherungsstartsektor werden Implementierungen dieses Felds als veraltet behandelt.

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.
VolumeDirty 1 1 Dieses Feld ist obligatorisch und Abschnitt 3.1.13.2 definiert seinen Inhalt.
MediaFailure 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 Field

Das ActiveFat-Feld beschreibt, welche FAT- und Zuordnungs-Bitmap aktiv sind (und Implementierungen verwendet werden), wie folgt:

  • 0, was bedeutet, dass die Erste FAT- und First Allocation Bitmap aktiv sind

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

Implementierungen sollten die inaktive FAT- und Zuordnungs-Bitmap als veraltet betrachten. Nur texFAT-bewusste Implementierungen müssen die aktiven FAT- und Zuordnungs-Bitmaps (siehe Abschnitt 7.1) wechseln.

3.1.13.2 VolumeDirty Field

Das Feld "VolumeDirty" beschreibt, ob die Lautstärke 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 Volumen wahrscheinlich in einem inkonsistenten Zustand befindet.

Implementierungen sollten den Wert dieses Felds auf 1 festlegen, wenn dateisystemmetadaten inkonsistent werden, die sie nicht auflösen. Wenn beim Anbringen eines Volumes der Wert dieses Felds 1 ist, können nur Implementierungen, die Dateisystemmetadaten 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 das Dateisystem in einem konsistenten Zustand ist.

Wenn bei der Installation eines Volumes der Wert dieses Felds 0 ist, sollten Implementierungen dieses Felds auf 1 festlegen, bevor Sie Dateisystemmetadaten aktualisieren und danach auf 0 löschen, ähnlich wie die empfohlene Schreibfolge in Abschnitt 8.1 beschrieben.

3.1.13.3 MediaFailure Field

Das Feld "MediaFailure" beschreibt, ob eine Implementierung Medienfehler festgestellt hat oder nicht, wie folgt:

  • 0, was bedeutet, dass die Hostingmedien keine Fehler gemeldet haben oder bekannte Fehler bereits im FAT als "schlechte" Cluster aufgezeichnet werden

  • 1, was bedeutet, dass die Hostingmedien Fehler gemeldet haben (d. h. fehler beim Lesen oder Schreiben von Vorgängen)

Eine Implementierung sollte dieses Feld auf 1 festlegen, wenn:

  1. Der Hostmedien hat keinen Zugriff auf alle Regionen im Volume

  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 für Medienfehler scannen und alle Fehler als "schlechte" Cluster im FAT (oder andernfalls auflösen) den Wert dieses Felds auf 0 löschen.

3.1.13.4 ClearToZero Field

Das ClearToZero-Feld 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 Implementierungen dieses Felds vor dem Ändern von Dateisystemstrukturen, Verzeichnissen oder Dateien auf 0 löschen.

3.1.14 BytesPerSectorShift Field

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

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

  • Mindestens 9 (Sektorgröße von 512 Bytes), die für ein exFAT-Volumen am kleinsten möglich ist

  • Am meisten 12 (Sektorgröße von 4096 Bytes), die die Speicherseitengröße von CPUs ist, die in persönlichen Computern üblich sind

3.1.15 SektorenPerClusterShift Field

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

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

  • Mindestens 0 (1 Sektor pro Cluster), der kleinste Cluster ist.

  • Am meisten 25 - BytesPerSectorShift, das auf eine Clustergröße von 32 MB ausgewertet wird

3.1.16 NumberOfFats Field

Das Feld "NumberOfFats" beschreibt die Anzahl der FATs und Allocation Bitmaps, 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 Bitmap" enthält

  • 2, das angibt, dass das Volumen das Erste 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 Field

Das Feld "DriveSelect" enthält die erweiterte INT 13h-Laufwerknummer, die das Startband von diesem Volume mithilfe erweiterter INT 13h auf persönlichen Computern unterstützt.

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

3.1.18 PercentInUse Field

Das Feld "PercentInUse" beschreibt den Prozentsatz von Clustern im Cluster-Heap, der zugewiesen wird.

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

  • Zwischen 0 und 100 inklusive, was der Prozentsatz der zugewiesenen Cluster im Cluster-Heap ist, wird auf die nächste ganze Ganze gerundet.

  • Genau FFh, der den Prozentsatz der zugewiesenen Cluster im Cluster-Heap angibt, ist nicht verfügbar.

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

Implementierungen umfassen dieses Feld nicht, wenn sie ihr jeweiliges Hauptstart- oder Sicherungsstartbereichscheckum berechnen. Bei Bezug auf den Sicherungsstartsektor werden Implementierungen dieses Felds als veraltet behandelt.

3.1.19 BootCode Field

Das Feld "BootCode" enthält Startbereifungsanweisungen. Implementierungen können dieses Feld mit den CPU-Anweisungen füllen, die für das Starten eines Computersystems erforderlich sind. Implementierungen, die keine Startbereifungsanweisungen bereitstellen, müssen jedes Byte in diesem Feld auf F4h initialisieren (die Stopp-Anweisung für CPUs, die in persönlichen Computern üblich sind) als Teil ihres Formatvorgangs.

3.1.20 BootSignature Field

Das Feld "BootSignature" beschreibt, ob es sich bei der Absicht eines bestimmten Sektors um einen Startsektor handelt oder nicht.

Der gültige Wert für dieses Feld ist AA55h. Jeder andere Wert in diesem Feld ungültig macht seinen jeweiligen Startsektor. Implementierungen sollten den Inhalt dieses Felds vor jedem anderen Feld in seinem jeweiligen Startsektor überprüfen.

3.2 Haupt- und Sicherung erweiterter Startsektoren

Jeder Sektor der Haupt-Erweiterten Startsektoren weist dieselbe Struktur auf; Jeder Sektor kann jedoch unterschiedliche Startbereifungsanweisungen enthalten (siehe Tabelle 6). Boot-Strapping-Agents, wie z. B. die Startbereifungsanweisungen im Hauptstartsektor, alternative BIOS-Implementierungen oder die Firmware eines eingebetteten Systems, können diese Sektoren laden und die anweisungen ausführen, die sie enthalten.

Die Sicherung erweiterter Startsektoren ist eine Sicherung der Haupt-Erweiterten Startsektoren und verfügt über die gleiche Struktur (siehe Tabelle 6).

Bevor Sie die Anweisungen des Haupt- oder Sicherungsbereichs für erweiterte Startsektoren ausführen, sollten Implementierungen ihren Inhalt überprüfen, indem sichergestellt wird, dass jedes Feld "ExtendedBootSignature" seinen vorgeschriebenen Wert enthält.

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

Tabelle 6 Erweiterte Startsektorstruktur

Feldname

Offset

(Byte)

Größe

(Bytes)

 Kommentare
ExtendedBootCode 0 2BytesPerSectorShift – 4

Dieses Feld ist obligatorisch und Abschnitt 3.2.1 definiert seinen Inhalt.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten beide das BytesPerSectorShift-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 BytesPerSectorShift-Feld.

3.2.1 ExtendedBootCode Field

Das Feld "ExtendedBootCode" enthält Startbereifungsanweisungen. Implementierungen können dieses Feld mit den CPU-Anweisungen füllen, die für das Starten eines Computersystems erforderlich sind. Implementierungen, die keine Startbereifungsanweisungen bereitstellen, müssen jedes Byte in diesem Feld als Teil des Formatvorgangs auf 00h initialisieren.

3.2.2 ExtendedBootSignature Field

Das Feld "ExtendedBootSignature" beschreibt, ob es sich um einen erweiterten Startsektor handelt oder nicht.

Der gültige Wert für dieses Feld ist AA550000h. Jeder andere Wert in diesem Feld ungültigt seinen jeweiligen Haupt- oder Sicherungs-Erweiterten Startsektor. Implementierungen sollten den Inhalt dieses Felds vor jedem anderen Feld in seinem jeweiligen erweiterten Startsektor überprüfen.

3.3 Haupt- und Sicherungs-OEM-Parameter Unterbereiche

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

Die Sicherungs-OEM-Parameter sind eine Sicherung der Haupt-OEM-Parameter und verfügt über die gleiche Struktur (siehe Tabelle 7).

Bevor Sie den Inhalt der Haupt- oder Sicherungs-OEM-Parameter verwenden, überprüfen Implementierungen ihre Inhalte, indem sie ihre jeweilige Startchecksumme überprüfen.

Hersteller sollten die Haupt- und Sicherungs-OEM-Parameter mit ihren eigenen benutzerdefinierten Parameterstrukturen auffüllen, falls vorhanden und andere Parameterstrukturen. Nachfolgende Formatvorgänge erhalten den Inhalt der Haupt- und Sicherungs-OEM-Parameter.

Implementierungen können die Haupt- und Sicherungs-OEM-Parameter nach Bedarf aktualisieren (und muss auch ihre jeweilige Startchecksumme 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 BytesPerSectorShift-Feld.

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

Jedes Parameterfeld in diesem Array enthält eine Parameterstruktur, die aus der Vorlage "Generische Parameter" abgeleitet wird (siehe Abschnitt 3.3.2). Jedes nicht verwendete Parameterfeld wird als Eine Nullparameterstruktur beschrieben (siehe Abschnitt 3.3.3).

Vorlage für generische Parameter 3.3.2

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 Field

Das Feld ParametersGuid 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 verwenden, z. B. GuidGen.exe, um eine GUID auszuwählen, wenn benutzerdefinierte Parameterstrukturen aus dieser Vorlage abgeleitet werden.

3.3.3 Nullparameter

Die Struktur "Null-Parameter" abgeleitet aus der Vorlage "Generische Parameter" (siehe Abschnitt 3.3.2) und beschreibt ein nicht verwendetes Parameterfeld (siehe Tabelle 9). Wenn Sie die OEM-Parameterstruktur erstellen oder aktualisieren, füllen Implementierungen nicht verwendete Parameterfelder mit der Struktur "Nullparameter" auf. Außerdem sollten Implementierungen beim Erstellen oder Aktualisieren der OEM-Parameterstruktur Nullparameterstrukturen am Ende des Arrays konsolidieren, wodurch alle anderen Parameterstrukturen am Anfang der OEM-Parameterstruktur verlassen werden.

Die Unterstützung für die Struktur "Null-Parameter" ist obligatorisch.

Tabelle 9 Nullparameterstruktur

Feldname

Offset

(Byte)

Größe

(Bytes)

 Kommentare
ParametersGuid 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 Field

Das Feld ParametersGuid entspricht der Definition der Vorlage "Generische Parameter" (siehe Abschnitt 3.3.2.1).

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

3.3.4 Blitzparameter

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

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

Tabelle 10 Blitzparameterstruktur

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.
ProgrammingTime 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 Blitzparameterfelder, außer für das ParameterGuid-Feld, sind gültig. Der Wert 0 gibt jedoch an, dass das Feld tatsächlich bedeutungslos ist (Implementierungen werden das angegebene Feld ignorieren).

3.3.4.1 ParametersGuid Field

Das Feld ParametersGuid entspricht der Definition in der Vorlage "Generische Parameter" (siehe Abschnitt 3.3.2.1).

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

3.3.4.2 EraseBlockSize Field

Das Feld "EraseBlockSize" beschreibt die Größe in Bytes des Löschblocks des Blitzmediens.

3.3.4.3 PageSize Field

Das Feld "PageSize" beschreibt die Größe in Bytes der Seite des Flashmediens.

3.3.4.4 SpareSectors Field

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

3.3.4.5 RandomAccessTime Field

Das Feld "RandomAccessTime" beschreibt die durchschnittliche zufällige Zugriffszeit des Blitzmediens in Nanosekunden.

3.3.4.6 ProgrammingTime Field

Das Feld "ProgrammingTime" beschreibt die durchschnittliche Programmierzeit der Flashmedien in Nanosekunden.

3.3.4.7 ReadCycle Field

Das Feld "ReadCycle" beschreibt die durchschnittliche Lesezykluszeit der Blitzmedien in Nanosekunden.

3.3.4.8 WriteCycle Field

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

3.4 Haupt- und Sicherungsstartüberprüfungen Unterbereiche

Die Haupt- und Sicherungsstartüberprüfungen enthalten jeweils ein wiederholtes Muster der vier byte-Prüfsumme der Inhalte 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 Startcheckum-Teilbereich vom Anfang bis zum Ende des Teilbereichs aus.

Vor der Verwendung des Inhalts einer der anderen Unterbereiche in den Haupt- oder Sicherungsstartbereichen müssen Implementierungen ihren Inhalt überprüfen, indem sie ihre jeweilige Startprüfungssumme überprüfen.

Während der anfängliche Formatvorgang sowohl die Haupt- als auch die Sicherungsstartchecksummen mit dem wiederholten Prüfumenmuster auffüllt, werden diese Bereiche aktualisiert, da sich die Inhalte der anderen Sektoren in ihren jeweiligen Startbereichen ändern.

Abbildung 1 Startchecksummenberechnung

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

Der Bereich "Dateizuordnungstabelle" (FAT) kann bis zu zwei FATs enthalten, eine in der Ersten FAT-Teilregion und eine andere in der Zweiten FAT-Teilregion. 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 der Teilbereich "First FAT" immer ein FAT. Wenn das Feld "NumberOfFats" zwei ist, enthält der Zweite FAT-Teilbereich auch ein FAT.

Das ActiveFat-Feld des VolumeFlags-Felds beschreibt, welche FAT aktiv ist. Nur das Feld "VolumeFlags" im Hauptstartsektor ist aktuell. Die Umsetzungen behandeln die FAT, die nicht als veraltet aktiv ist. Die Verwendung der inaktiven FAT und das Wechseln zwischen FATs ist speziell.

4.1 Erste und zweite FAT-Teilbereiche

Eine FAT beschreibt Clusterketten im Cluster-Heap (siehe Tabelle 11). Eine Clusterkette ist eine Reihe von Clustern, die Platz für die Aufzeichnung der Inhalte von Dateien, Verzeichnissen und anderen Dateisystemstrukturen bieten. Ein FAT stellt eine Clusterkette als singly verknüpfte Liste der 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 FFFFFFFFF6h nie überschreiten.

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

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

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

4.1.1 FatEntry[0] Field

Das Feld FatEntry[0] beschreibt den Medientyp im ersten Byte (dem niedrigsten Byte) und enthält FFh in den verbleibenden drei Bytes.

Der Medientyp (das erste Byte) sollte F8h sein.

4.1.2 FatEntry[1] Feld

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

Der gültige Wert für dieses Feld ist FFFFFFFFFFh. Implementierungen initialisieren dieses Feld auf ihren vorgeschriebenen Wert und sollten dieses Feld nicht für einen bestimmten Zweck verwenden. Implementierungen sollten dieses Feld nicht interpretieren und ihre Inhalte über Vorgänge beibehalten, die umgebende Felder ändern.

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

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

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

  • Zwischen 2 und ClusterCount + 1, inklusive, die auf die nächste FatEntry in der angegebenen Clusterkette verweist; die angegebene FatEntry weist keine FatEntry auf, die ihm in der angegebenen Clusterkette vorangestellt ist.

  • Genau FFFFFFFFF7h, das den entsprechenden Cluster von FatEntry als "schlecht" markiert.

  • Genau FFFFFFFFFFh, das den entsprechenden Cluster von FatEntry als letzten Cluster einer Clusterkette markiert; dies ist der einzige gültige Wert für die letzte FatEntry einer bestimmten Clusterkette

5 Datenbereich

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-Heaps ist sehr einfach (siehe Tabelle 12); Jede aufeinander folgende Reihe von Sektoren beschreibt einen Cluster, da das Feld "SectorsPerClusterShift" definiert. Wichtig ist, dass der erste Cluster des Cluster-Heap index zwei hat, der direkt dem Index von FatEntry[2] entspricht.

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

Tabelle 12 Cluster-Heapstruktur

Feldname

Offset

(Sektor)

Größe

(Sektoren)

 Kommentare
Cluster[2] ClusterHeapOffset 2SektorenPerClusterShift

Dieses Feld ist obligatorisch und Abschnitt 5.1.1 definiert seinen Inhalt.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten sowohl die Felder "ClusterHeapOffset" als auch "SectorsPerClusterShift".

.

.

.

.

.

.

.

.

.

.

.

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

Dieses Feld ist obligatorisch und Abschnitt 5.1.1 definiert seinen Inhalt.

Hinweis: Die Haupt- und Sicherungsstartsektoren enthalten sowohl die Felder "ClusterCount", "ClusterHeapOffset" als auch "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 zum Verwalten der Dateisystemstrukturen und Dateien, die im Cluster-Heap vorhanden sind. Verzeichnisse verfügen über eine 1-0-Beziehung zwischen übergeordnetem und untergeordnetem Element in der Verzeichnisstruktur.

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

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

Ein oder mehrere Verzeichniseinträge kombinieren sich in einem Verzeichniseintragssatz, der etwas Interesse 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.

.

.

.

.

.

.

.

.

.

.

.

.
DirectoryEntry[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 in Bytes der Clusterkette, die das angegebene Verzeichnis enthält, unterteilt durch die Größe eines DirectoryEntry-Felds, 32 Bytes.

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

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

6.2 Generic DirectoryEntry-Vorlage

Die Generische DirectoryEntry-Vorlage stellt die Basisdefinition für Verzeichniseinträge bereit (siehe Tabelle 14). Alle Verzeichniseintragsstrukturen stammen aus dieser Vorlage und nur von Microsoft definierte Verzeichniseintragsstrukturen sind gültig (exFAT verfügt nicht über Bestimmungen für herstellerdefinierte Verzeichniseintragsstrukturen außer in Abschnitt 7.8 und Abschnitt 7.9). Die Möglichkeit, die Generic DirectoryEntry-Vorlage zu interpretieren, ist obligatorisch.

Tabelle 14 Generische VerzeichnisEntry-Vorlage

Feldname

Offset

(Byte)

Größe

(Byte)

 Kommentare
EntryType 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.
DataLength 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, die eine End-of-Directory-Markierung ist und die folgenden Bedingungen gelten:

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

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

    • End-of-Directory-Markierungen sind nur außerhalb von Verzeichniseintragssätzen gültig.

    • Implementierungen können End-of-Directory-Marker nach Bedarf überschreiben

  • Zwischen 01h und 7Fh inklusive, die eine nicht verwendete Verzeichniseintragsmarkierung und die folgenden Bedingungen gelten:

    • Alle anderen Felder in der angegebenen DirectoryEntry sind tatsächlich nicht definiert.

    • Nicht verwendete Verzeichniseinträge sind nur außerhalb von Verzeichniseintragssätzen gültig.

    • Implementierungen können nicht verwendete Verzeichniseinträge nach Bedarf überschreiben.

    • Dieser Wertebereich entspricht dem InUse-Feld (siehe Abschnitt 6.2.1.4), der den Wert 0 enthält.

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

    • Der Inhalt des EntryType-Felds (siehe Tabelle 15) bestimmt das Layout der restlichen DirectoryEntry-Struktur.

    • Dieser Wertebereich und nur dieser Wertebereich sind in einem Verzeichniseintragssatz gültig.

    • Dieser Wertebereich entspricht direkt dem InUse-Feld (siehe Abschnitt 6.2.1.4), der den Wert 1 enthält.

Um Änderungen an dem InUse-Feld zu verhindern (siehe Abschnitt 6.2.1.4), die zu einer End-of-Directory-Markierung 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 Abschnitt 6.2.1.1 definiert seinen Inhalt.
TypeImportance 5 1 Dieses Feld ist obligatorisch und Abschnitt Abschnitt 6.2.1.2 definiert seinen Inhalt.
TypeCategory 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 Feld TypeCode 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 Field

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

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

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 Field

Das Feld InUse beschreibt, 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 Clusterzuweisung vorhanden ist

  • Zwischen 2 und ClusterCount + 1, das ist der Bereich der gültigen 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 Field

Das Feld "DataLength" beschreibt die Größe der Daten, 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 wert 0 des Felds nur gültig.

  • Am meisten 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ärer Verzeichniseintrag. Alle nachfolgenden Verzeichniseinträge( sofern vorhanden) im Verzeichniseintragssatz sind sekundäre Verzeichniseinträge (siehe Abschnitt 6.4).

Die Möglichkeit, die generische Primäre VerzeichnisEntry-Vorlage zu interpretieren, ist obligatorisch.

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

Tabelle 16 Generische Primäre Verzeichnisentry-Vorlage

Feldname

Offset

(Byte)

Größe

(Byte)

 Kommentare
EntryType 0 1 Dieses Feld ist obligatorisch und Abschnitt 6.3.1 definiert seinen Inhalt.
SecondaryCount 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.
GeneralPrimaryFlags 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 werden, definieren den Inhalt.
FirstCluster 20 4 Dieses Feld ist obligatorisch und Abschnitt 6.3.5 definiert seinen Inhalt.
DataLength 24 8 Dieses Feld ist obligatorisch und Abschnitt 6.3.6 definiert seinen Inhalt.

6.3.1 EntryType Field

Das Feld "EntryType" entspricht der Definition, die in der Vorlage "Generic DirectoryEntry" (siehe Abschnitt 6.2.1) angegeben ist.

6.3.1.1 TypeCode Field

Das Feld "TypeCode" entspricht der Definition in der Vorlage "Generic DirectoryEntry" (siehe Abschnitt 6.2.1.1).

6.3.1.2 TypeImportance Field

Das Feld "TypeImportance" entspricht der Definition, die in der Generischen DirectoryEntry-Vorlage angegeben ist (siehe Abschnitt 6.2.1.2).

6.3.1.2.1 Kritische 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 wichtigsten ExFAT-Revisionsnummer. Implementierungen unterstützen alle kritischen primären Verzeichniseinträge und zeichnen nur die kritischen primären Verzeichniseintragsstrukturen auf, die diese Spezifikation definiert.

6.3.1.2.2 Gutartige Primärverzeichniseinträ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 Nebenversionsnummer exFAT. Unterstützung für jeden gutartigen primären Verzeichniseintrag dieser Spezifikation oder einer nachfolgenden Spezifikation ist optional. Ein nicht erkannter nicht erkannter primärer Verzeichniseintrag rendert den gesamten Verzeichniseintragssatz als nicht erkannt (über die Definition der anwendbaren Verzeichniseintragsvorlagen hinaus).

6.3.1.3 TypeCategory Field

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 Field

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

6.3.2 SecondaryCount Field

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

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

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

  • Am meisten 255, was bedeutet, dass die nächsten 255 Verzeichniseinträge und dieser primäre Verzeichniseintrag den Verzeichniseintragssatz umfasst.

Kritische 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" enthält die Prüfsumme aller Verzeichniseinträge im angegebenen Verzeichniseintragssatz. Die Prüfsumme schließt dieses Feld jedoch aus (siehe Abbildung 2). Implementierungen überprüfen den Inhalt dieses Felds vor der Verwendung eines anderen Verzeichniseintrags im angegebenen Verzeichniseintrag.

Kritische 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 AllgemeinePrimaryFlags-Feldstruktur

Feldname

Offset

(bit)

Größe

(Bits)

 Kommentare
AllocationPossible 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" beschreibt, ob eine Zuordnung im Cluster-Heap für den angegebenen Verzeichniseintrag 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 aus 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 die 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 Implementierungen 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 dieser Feld nur gültiger Wert 0.

  • 1, was bedeutet, dass die zugeordnete Zuordnung eine zusammenhängende Reihe von Clustern ist; die entsprechenden FAT-Einträge für die Cluster ungültig sind und Implementierungen nicht interpretiert werden; Implementierungen können die folgende Formel verwenden, um die Größe der zugeordneten Zuordnung zu berechnen: DataLength / (2SectorsPerClusterShift* 2 BytesPerSectorShift) auf die nächste ganze Zahlgerundet

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

6.3.5 FirstCluster Field

Das Feld "FirstCluster" entspricht der Definition in der Vorlage "Generic DirectoryEntry" (siehe Abschnitt 6.2.2.2).

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

Kritische Primäre Verzeichniseintragsstrukturen, 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 DataLength Field

Das Feld "DataLength" entspricht der Definition in der Vorlage "Generic DirectoryEntry" (siehe Abschnitt 6.2.3).

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

Kritische Primäre Verzeichniseintragsstrukturen, 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 Generic Secondary DirectoryEntry-Vorlage

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 Nebenversionsnummer der ExFAT-Revision. Unterstützung für kritische oder gutartige sekundäre Verzeichniseinträge, die diese Spezifikation oder nachfolgende Spezifikationen definieren, ist optional.

Alle sekundären Verzeichniseintragsstrukturen stammen aus der Vorlage "Generic Secondary DirectoryEntry" (siehe Tabelle 18), die aus der Vorlage "Generic DirectoryEntry" abgeleitet wird (siehe Abschnitt 6.2).

Tabelle 18 Generische SekundärverzeichnisEntry-Vorlage

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 Abschnitt 6.4.2 definiert seinen Inhalt.
CustomDefined 2 18 Dieses Feld ist obligatorisch und Strukturen, die von dieser Vorlage abgeleitet werden, definieren ihren Inhalt.
FirstCluster 20 4 Dieses Feld ist obligatorisch und Abschnitt 6.4.3 definiert seinen Inhalt.
DataLength 24 8 Dieses Feld ist obligatorisch und Abschnitt 6.4.4 definiert seinen Inhalt.

6.4.1 EntryType Field

Das EntryType-Feld entspricht der Definition, die in der Generischen VerzeichnisEntry-Vorlage bereitgestellt wird (siehe Abschnitt 6.2.1)

6.4.1.1 TypeCode Field

Das Feld "TypeCode" entspricht der Definition in der Vorlage "Generic DirectoryEntry" (siehe Abschnitt 6.2.1.1).

6.4.1.2 TypeImportance Field

Das Feld "TypeImportance" entspricht der Definition, die in der Generischen VerzeichnisEntry-Vorlage bereitgestellt wird (siehe Abschnitt 6.2.1.2).

6.4.1.2.1 Kritische sekundäre Verzeichniseinträge

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

Wenn jedoch ein Verzeichniseintragssatz mindestens einen kritischen sekundären Verzeichniseintrag enthält, den eine Implementierung nicht erkennt, interpretiert die Implementierung am meisten die Vorlagen der Verzeichniseinträge im Verzeichniseintragssatz und nicht die Daten, die einem Verzeichniseintrag im Verzeichniseintragssatz zugeordnet sind, enthält (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 das Verwalten des enthaltenen Verzeichniseintragssatzes nützlich sein können. Die Unterstützung für einen bestimmten gutartigen sekundären Verzeichniseintrag ist optional. Nicht erkannte sekundäre Verzeichniseinträge rendern nicht den gesamten Verzeichniseintrag als nicht erkannt.

Implementierungen können einen gutartigen sekundären Eintrag ignorieren, der nicht erkannt wird.

6.4.1.3 TypeCategory Field

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 Field

Das InUse-Feld 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 Generische AllgemeineSecondaryFlags-Feldstruktur

Feldname

Offset

(bit)

Größe

(Bits)

 Kommentare
AllocationPossible 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 AllocationPossible Field

Das Feld "AllocationPossible" hat dieselbe Definition wie das gleiche benannte Feld in der Vorlage "Generic Primary DirectoryEntry" (siehe Abschnitt 6.3.4.1).

6.4.2.2 NoFatChain Field

Das Feld "NoFatChain" hat dieselbe Definition wie das gleiche benannte Feld in der Vorlage "Generic Primary DirectoryEntry" (siehe Abschnitt 6.3.4.2).

6.4.3 FirstCluster Field

Das Feld "FirstCluster" entspricht der Definition in der Vorlage "Generic DirectoryEntry" (siehe Abschnitt 6.2.2.2).

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

6.4.4 DataLength Field

Das Feld "DataLength" entspricht der Definition in der Vorlage "Generic DirectoryEntry" (siehe Abschnitt 6.2.3).

Wenn der NoFatChain-Bit 1 ist, muss DataLength nicht null sein. Wenn das Feld "FirstCluster" null ist, muss DataLength auch 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 wird eine Zuordnungs-Bitmap verwendet. Zuordnungs-Bitmaps sind im Cluster-Heap 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 der gültigen Zuordnungs-Bitmap-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 einzige Zuordnungs-Bitmap-Eintrag gültig, wenn er die First Allocation Bitmap 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. Darüber hinaus sind die beiden Zuordnungs-Bitmap-Einträge nur gültig, wenn eine die Erste Zuordnungs bitmap beschreibt und die andere die zweite Zuordnungs bitmap beschreibt.

Tabelle 20 Zuordnungs-BitmapverzeichnisEntry-Struktur

Feldname

Offset

(Byte)

Größe

(Byte)

 Kommentare
EntryType 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.
DataLength 24 8 Dieses Feld ist obligatorisch und Abschnitt 7.1.4 definiert seinen Inhalt.

7.1.1 EntryType Field

Das Feld "EntryType" entspricht der Definition, die in der Vorlage "Generic Primary DirectoryEntry" bereitgestellt wird (siehe Abschnitt 6.3.1).

7.1.1.1 TypeCode Field

Das Feld "TypeCode" entspricht der Definition, die in der Vorlage "Generic Primary DirectoryEntry" bereitgestellt wird (siehe Abschnitt 6.3.1.1).

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

7.1.1.2 TypeImportance Field

Das Feld "TypeImportance" entspricht der Definition, die in der Vorlage "Generic Primary DirectoryEntry" angegeben ist (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" entspricht der Definition in der Vorlage "Generic Primary DirectoryEntry" (siehe Abschnitt 6.3.1.3).

7.1.1.4 InUse Field

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

7.1.2 BitmapFlags Field

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 BitmapIdentifier-Feld muss angeben, welche Zuordnungs-Bitmap der angegebene Verzeichniseintrag beschreibt. Implementierungen verwenden die Erste Zuordnungs-Bitmap in Verbindung mit dem ersten FAT und verwenden die zweite Zuordnungs-Bitmap in Verbindung mit dem zweiten FAT. Das ActiveFat-Feld beschreibt, welche FAT- und Zuordnungs-Bitmap aktiv sind.

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

  • 0, was bedeutet, dass der angegebene Verzeichniseintrag die Erste Zuordnungs-Bitmap beschreibt

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

7.1.3 FirstCluster Field

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

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

7.1.4 DataLength Field

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

7.1.5-Zuordnungs-Bitmap

Eine Zuordnungs-Bitmap zeichnet den Zuordnungsstatus der Cluster im Cluster-Heap auf. Jedes Bit in einer Zuordnungs-Bitmap 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 hat der erste Cluster Index 2. Hinweis: Das erste Bit in der Bitmap ist das kleinste Bit des ersten Bytes.

Tabelle 22 Zuordnungs-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 Der 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 dessen Inhalte sind 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] dar, der den letzten Cluster im Cluster-Heap darstellt.

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 nutzen oder das aktive FAT den entsprechenden Cluster als schlecht beschreiben)

7.2 Verzeichniseintrag in Groß-/Kleinschreibung

In der Groß-/Kleinschreibungstabelle wird die Konvertierung von Kleinbuchstaben in Groß-/Kleinschreibung definiert. Dies ist aufgrund des Verzeichniseintrags "Dateiname" (siehe Abschnitt 7.7) mit Unicode-Zeichen und dem exFAT-Dateisystem wichtig, bei dem die Groß- und Kleinschreibung nicht beachtet wird. Die Up-Case-Tabelle ist im Cluster-Heap 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 von Verzeichniseinträgen in Up-Case-Tabellen ist 1.

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

Table 23 Up-case Table DirectoryEntry-Struktur

Feldname

Offset

(Byte)

Größe

(Byte)

 Kommentare
EntryType 0 1 Dieses Feld ist obligatorisch und Abschnitt 7.2.1 definiert seinen Inhalt.
Reserved1 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.
Reserved2 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.
DataLength 24 8 Dieses Feld ist obligatorisch und Abschnitt 7.2.4 definiert seinen Inhalt.

7.2.1 EntryType Field

Das Feld "EntryType" entspricht der Definition, die in der Vorlage "Generic Primary DirectoryEntry" bereitgestellt wird (siehe Abschnitt 6.3.1).

7.2.1.1 TypeCode Field

Das Feld "TypeCode" entspricht der Definition, die in der Vorlage "Generic Primary DirectoryEntry" bereitgestellt wird (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" entspricht der Definition, die in der Vorlage "Generic Primary DirectoryEntry" bereitgestellt wird (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 InUse-Feld entspricht der Definition, die in der Vorlage "Generic Primary DirectoryEntry" bereitgestellt wird (siehe Abschnitt 6.3.1.4).

7.2.2 TableChecksum Field

Das Feld "TableChecksum" enthält die Prüfsumme der Groß-/Kleinschreibungstabelle (die die Felder "FirstCluster" und "DataLength" beschreiben). Implementierungen überprüfen, ob der Inhalt dieses Felds vor der Verwendung der Falltabelle gültig ist.

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" entspricht der Definition in der Vorlage "Generic Primary DirectoryEntry" (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" entspricht der Definition in der Vorlage "Generic Primary DirectoryEntry" (siehe Abschnitt 6.3.6).

7.2.5 Up-Case-Tabelle

Eine Groß-/Kleinschreibungstabelle ist eine Reihe von Unicode-Zeichenzuordnungen. Eine Zeichenzuordnung besteht aus einem 2-Byte-Feld mit dem Index des Felds in der Groß-/Kleinschreibungstabelle, das das Unicode-Zeichen darstellt, das groß- und klein geschrieben werden soll, und das 2-Byte-Feld, das das Groß-/Kleinschreibungszeichen darstellt.

Die ersten 128 Unicode-Zeichen verfügen über obligatorische Zuordnungen (siehe Tabelle 24). Eine Groß-/Kleinschreibungstabelle, die eine andere Zeichenzuordnung für eine der ersten 128 Unicode-Zeichen aufweist, ist ungültig.

Implementierungen, die nur Zeichen aus dem obligatorischen Zuordnungsbereich unterstützen, können die Zuordnungen der restlichen Falltabelle ignorieren. Diese Implementierungen verwenden nur Zeichen aus dem obligatorischen Zuordnungsbereich beim Erstellen oder Umbenennen von Dateien (über den Dateinamenverzeichniseintrag, siehe Abschnitt 7.7). Bei der Aktualisierung vorhandener Dateinamen müssen solche Implementierungen keine Groß-/Kleinschreibungszeichen aus dem nicht obligatorischen Zuordnungsbereich aufweisen, sondern sie in der resultierenden Groß-/Kleinschreibung intakt lassen (dies ist eine teilweise Up-Casing). Beim Vergleich von Dateinamen behandelt diese Implementierung Dateinamen, die sich von dem Namen unterscheiden, der sich nur von Unicode-Zeichen aus dem nicht obligatorischen Zuordnungsbereich als gleichwertig unterscheidet. Während solche Dateinamen nur potenziell gleichwertig sind, können solche Implementierungen nicht sicherstellen, dass der vollständig nach oben beschriebene Dateinamen nicht mit dem Namen im Vergleich kollidiert.

Tabelle 24 Obligatorische erste 128 Groß-/Kleinschreibungstabelleneinträge

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)

Bei der Formatierung 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 von Groß-/Kleinschreibung aufweist (was bedeutet, dass die Zeichen "Kleinschreibung" und "Groß-/Kleinschreibung" gleichwertig sind). Implementierungen komprimieren eine Falltabelle, indem sie eine Reihe von Identitätszuordnungen mit dem Wert FFFFh darstellt, gefolgt von der Anzahl der Identitätszuordnungen.

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

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

Die ersten beiden Einträge deuten darauf hin, dass die ersten 97 (61h) Zeichen (von 0000h bis 0060h) Identitätszuordnungen aufweisen. Die nachfolgenden Zeichen, 0061h bis 0063h, ordnen sie den Zeichen 0041h bis 0043h zu.

Die Möglichkeit, bei der Formatierung eines Volumes eine komprimierte Groß-/Kleinschreibungstabelle bereitzustellen, ist optional. Die Möglichkeit, sowohl eine nicht komprimierte als auch eine komprimierte Groß-/Kleinschreibungstabelle zu interpretieren, ist jedoch obligatorisch. Der Wert des TableChecksum-Felds entspricht immer der Art, wie die Groß-/Kleinschreibungstabelle auf dem Volume vorhanden ist, die möglicherweise in komprimierter oder unkomprimiertem Format enthalten ist.

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

Wenn eine Implementierung eine eigene Groß-/Kleinschreibungstabelle definiert, entweder komprimiert oder nicht komprimiert, wird diese Tabelle den vollständigen Unicode-Zeichenbereich abdecken (von Zeichencodes 0000h bis FFFFh inklusive).