Partager via

Spécification du système de fichiers exFAT

1 Introduction

Le système de fichiers exFAT est le successeur de FAT32 dans la famille FAT des systèmes de fichiers. Cette spécification décrit le système de fichiers exFAT et fournit toutes les informations nécessaires à l’implémentation du système de fichiers exFAT.

1.1 Objectifs de conception

Le système de fichiers exFAT a trois objectifs de conception centraux (voir la liste ci-dessous).

  1. Conserver la simplicité des systèmes de fichiers basés sur FAT.

    Deux des points forts des systèmes de fichiers basés sur FAT sont leur simplicité relative et leur facilité d’implémentation. Dans l’esprit de ses prédécesseurs, les implémenteurs devraient trouver exFAT relativement simple et facile à implémenter.

  2. Activer des fichiers et des périphériques de stockage très volumineux.

    Le système de fichiers exFAT utilise 64 bits pour décrire la taille de fichier, ce qui permet aux applications qui dépendent de fichiers très volumineux. Le système de fichiers exFAT permet également des clusters aussi volumineux que 32 Mo, ce qui permet efficacement des périphériques de stockage très volumineux.

  3. Incorporer l’extensibilité pour l’innovation future.

    Le système de fichiers exFAT intègre l’extensibilité dans sa conception, ce qui permet au système de fichiers de suivre les innovations dans le stockage et les changements d’utilisation.

1.2 Terminologie spécifique

Dans le contexte de cette spécification, certains termes (voir Tableau 1) portent une signification spécifique pour la conception et l’implémentation du système de fichiers exFAT.

tableau 1 définition des termes qui portent une signification très spécifique

terme définition
Est Cette spécification utilise le terme « doit » pour décrire un comportement obligatoire.
Devoir Cette spécification utilise le terme « doit » pour décrire un comportement qu’il recommande fortement, mais ne rend pas obligatoire.
Mai Cette spécification utilise le terme « may » pour décrire un comportement facultatif.
Obligatoire Ce terme décrit un champ ou une structure qu’une implémentation doit modifier et interpréter comme décrit cette spécification.
Optionnel Ce terme décrit un champ ou une structure qu’une implémentation peut ou non prendre en charge. Si une implémentation prend en charge un champ ou une structure facultatif donné, elle doit modifier et interpréter le champ ou la structure comme décrit cette spécification.
Indéfini Ce terme décrit le contenu de champ ou de structure qu’une implémentation peut modifier si nécessaire (c’est-à-dire effacer sur zéro lors de la définition de champs ou de structures environnants) et ne doit pas interpréter pour contenir une signification spécifique.
Réservé

Ce terme décrit le contenu du champ ou de la structure que les implémentations :

  1. Initialiser à zéro et ne doit pas être utilisé à des fins quelconques

  2. Ne doit pas interpréter, sauf lors de l’informatique des sommes de contrôle

  3. Conserver les opérations qui modifient les champs ou structures environnants

1.3 Texte intégral d’acronymes communs

Cette spécification utilise des acronymes en usage courant dans le secteur de l’ordinateur personnel (voir Tableau 2).

tableau 2 texte intégral des acronymes communs

acronyme de texte intégral
ASCII Code standard américain pour l’échange d’informations
BIOS Système de sortie d’entrée de base
CPU Unité de traitement centralisée
exFAT table d’allocation de fichiers extensible
GRAISSE Table d’allocation de fichiers
FAT12 Table d’allocation de fichiers, index de cluster 12 bits
FAT16 Table d’allocation de fichiers, index de cluster 16 bits
FAT32 Table d’allocation de fichiers, index de cluster 32 bits
GPT Table de partition GUID
GUID Identificateur global unique (voir section 10.1)
INT Interrompre
MBR Enregistrement de démarrage principal
texFAT ExFAT sécurisé pour les transactions
UTC Temps universel coordonné

1.4 Qualificateurs de champ et de structure par défaut

Les champs et les structures de cette spécification ont les qualificateurs suivants (voir la liste ci-dessous), sauf indication contraire de la spécification.

  1. Ne sont pas signés

  2. Utilisez la notation décimale pour décrire les valeurs, où elles ne sont pas notées ; cette spécification utilise la lettre post-fix « h » pour indiquer les nombres hexadécimaux et placer les GUID dans des accolades

  3. Sont au format little-endian

  4. Ne pas nécessiter de caractère de fin null pour les chaînes

1.5 Windows CE et TexFAT

TexFAT est une extension à exFAT qui ajoute la sémantique opérationnelle sécurisée par transaction au-dessus du système de fichiers de base. TexFAT est utilisé par Windows CE. TexFAT nécessite l’utilisation des deux images bitmap d’allocation et des deux fats pour une utilisation dans les transactions. Il définit également plusieurs structures supplémentaires, notamment les descripteurs de remplissage et les descripteurs de sécurité.

Structure de volume 2

Un volume est l’ensemble de toutes les structures et espaces de données du système de fichiers nécessaires pour stocker et récupérer les données utilisateur. Tous les volumes exFAT contiennent quatre régions (voir Tableau 3).

tableau 3 structure de volume

nom de sous-région

offset

(secteur)

taille

(secteurs)

 commentaires
région de démarrage principale
Secteur de démarrage principal 0 1 Cette sous-région est obligatoire et section 3.1 définit son contenu.
Principaux secteurs de démarrage étendus 1 8 Cette sous-région est obligatoire et section 3.2) définit son contenu.
Principaux paramètres OEM 9 1 Cette sous-région est obligatoire et section 3.3 définit son contenu.
Principal réservé 10 1 Cette sous-région est obligatoire et son contenu est réservé.
Somme de contrôle de démarrage principale 11 1 Cette sous-région est obligatoire et section 3.4 définit son contenu.
région de démarrage de sauvegarde
Secteur de démarrage de la sauvegarde 12 1 Cette sous-région est obligatoire et section 3.1 définit son contenu.
Secteurs de démarrage étendus de sauvegarde 13 8 Cette sous-région est obligatoire et section 3.2 définit son contenu.
Paramètres OEM de sauvegarde Vingt-et-un 1 Cette sous-région est obligatoire et section 3.3 définit son contenu.
Sauvegarde réservée 22 1 Cette sous-région est obligatoire et son contenu est réservé.
Somme de contrôle de démarrage de sauvegarde 23 1 Cette sous-région est obligatoire et section 3.4 définit son contenu.
de la région FAT
Alignement FAT Vingt-quatre FatOffset – 24

Cette sous-région est obligatoire et son contenu, le cas échéant, ne sont pas définis.

Remarque : les secteurs de démarrage principal et de sauvegarde contiennent tous deux le champ FatOffset.
Première FAT FatOffset LongueurGrasse

Cette sous-région est obligatoire et section 4.1 définit son contenu.

Remarque : les secteurs de démarrage principal et de sauvegarde contiennent les champs FatOffset et FatLength.
Deuxième FAT FatOffset + FatLength FatLength * (NumberOfFats – 1)

Cette sous-région est obligatoire et section 4.1 définit son contenu, le cas échéant.

Remarque : les secteurs de démarrage principal et de sauvegarde contiennent les champs FatOffset, FatLength et NumberOfFats. Le champ NumberOfFats ne peut contenir que les valeurs 1 et 2.
région de données
Alignement du tas de cluster FatOffset + FatLength * NumberOfFats ClusterHeapOffset – (FatOffset + FatLength * NumberOfFats)

Cette sous-région est obligatoire et son contenu, le cas échéant, ne sont pas définis.

Remarque : les secteurs de démarrage principal et de sauvegarde contiennent les champs FatOffset, FatLength, NumberOfFats et ClusterHeapOffset. Les valeurs valides du champ NumberOfFats sont 1 et 2.
Tas de cluster ClusterHeapOffset ClusterCount * 2 secteursPerClusterShift

Cette sous-région est obligatoire et section 5.1 définit son contenu.

Remarque : les secteurs de démarrage principal et de sauvegarde contiennent tous deux les champs ClusterHeapOffset, ClusterCount et SectorsPerClusterShift.
Espace excédentaire ClusterHeapOffset + ClusterCount * 2 secteursPerClusterShift VolumeLength – (ClusterHeapOffset + ClusterCount * 2SectorsPerClusterShift)

Cette sous-région est obligatoire et son contenu, le cas échéant, ne sont pas définis.

Remarque : les secteurs de démarrage principal et de sauvegarde contiennent tous deux les champs ClusterHeapOffset, ClusterCount, SectorsPerClusterShift et VolumeLength.

3 régions de démarrage principales et de sauvegarde

La région principale de démarrage fournit toutes les instructions de sanglage de démarrage nécessaires, l’identification des informations et les paramètres du système de fichiers pour permettre à une implémentation d’effectuer les opérations suivantes :

  1. Sangle de démarrage un système informatique à partir d’un volume exFAT.
  2. Identifiez le système de fichiers sur le volume comme exFAT.
  3. Découvrez l’emplacement des structures du système de fichiers exFAT.

La région de démarrage de sauvegarde est une sauvegarde de la région de démarrage principale. Il facilite la récupération du volume exFAT en cas de région principale de démarrage dans un état incohérent. Sauf dans des circonstances peu fréquentes, telles que la mise à jour des instructions de sanglage de démarrage, les implémentations ne doivent pas modifier le contenu de la région de démarrage de sauvegarde.

3.1 Sous-régions du secteur de démarrage principal et de sauvegarde

Le secteur de démarrage principal contient du code pour le sanglage de démarrage à partir d’un volume exFAT et des paramètres exFAT fondamentaux qui décrivent la structure du volume (voir Tableau 4). BIOS, MBR ou d’autres agents de sanglage de démarrage peuvent inspecter ce secteur et peuvent charger et exécuter toutes les instructions de sangles de démarrage contenues dans ce secteur.

Le secteur de démarrage de sauvegarde est une sauvegarde du secteur de démarrage principal et a la même structure (voir Tableau 4). Le secteur de démarrage de sauvegarde peut aider les opérations de récupération ; toutefois, les implémentations traitent le contenu des champs VolumeFlags et PercentInUse comme obsolètes.

Avant d’utiliser le contenu du secteur de démarrage principal ou de sauvegarde, les implémentations vérifient leur contenu en validant leur somme de contrôle de démarrage respective et en veillant à ce que tous leurs champs se trouvent dans leur plage de valeurs valide.

Bien que l’opération de mise en forme initiale initial initialise le contenu des secteurs de démarrage principal et de sauvegarde, les implémentations peuvent mettre à jour ces secteurs (et mettent également à jour leur somme de contrôle de démarrage respective) si nécessaire. Toutefois, les implémentations peuvent mettre à jour les champs VolumeFlags ou PercentInUse sans mettre à jour leur somme de contrôle de démarrage respective (la somme de contrôle exclut spécifiquement ces deux champs).

Table 4 Structure du secteur de démarrage principal et de sauvegarde

nom de champ

offset

(octets)

taille

(octets)

 commentaires
JumpBoot 0 3 Ce champ est obligatoire et section 3.1.1 définit son contenu.
NomDuSystèmeDeFichiers 3 8 Ce champ est obligatoire et section 3.1.2 définit son contenu.
MustBeZero 11 53 Ce champ est obligatoire et section 3.1.3 définit son contenu.
PartitionOffset 64 8 Ce champ est obligatoire et section 3.1.4 définit son contenu.
LongueurVolume 72 8 Ce champ est obligatoire et section 3.1.5 définit son contenu.
FatOffset 80 4 Ce champ est obligatoire et section 3.1.6 définit son contenu.
LongueurGrasse 84 4 Ce champ est obligatoire et section 3.1.7 définit son contenu.
ClusterHeapOffset 88 4 Ce champ est obligatoire et section 3.1.8 définit son contenu.
Nombre de Clusters 92 4 Ce champ est obligatoire et section 3.1.9 définit son contenu.
FirstClusterOfRootDirectory 96 4 Ce champ est obligatoire et section 3.1.10 définit son contenu.
VolumeSerialNumber 100 4 Ce champ est obligatoire et section 3.1.11 définit son contenu.
Révision du système de fichiers 104 2 Ce champ est obligatoire et section 3.1.12 définit son contenu.
VolumeFlags 01:23:06 AM 2 Ce champ est obligatoire et section 3.1.13 définit son contenu.
BytesPerSectorShift 108 1 Ce champ est obligatoire et section 3.1.14 définit son contenu.
SectorsPerClusterShift 109 1 Ce champ est obligatoire et section 3.1.15 définit son contenu.
NumberOfFats 110 1 Ce champ est obligatoire et section 3.1.16 définit son contenu.
DriveSelect 111 1 Ce champ est obligatoire et section 3.1.17 définit son contenu.
PourcentageUtilisé 112 1 Ce champ est obligatoire et section 3.1.18 définit son contenu.
Réservé 113 7 Ce champ est obligatoire et son contenu est réservé.
BootCode 120 390 Ce champ est obligatoire et section 3.1.19 définit son contenu.
BootSignature 510 2 Ce champ est obligatoire et section 3.1.20 définit son contenu.
ExcessSpace 512 2BytesPerSectorShift – 512

Ce champ est obligatoire et son contenu, le cas échéant, ne sont pas définis.

Remarque : les secteurs de démarrage principal et de sauvegarde contiennent tous deux le champ BytesPerSectorShift.

3.1.1 Champ JumpBoot

Le champ JumpBoot contient l’instruction de saut pour les processeurs communs aux ordinateurs personnels, qui, lorsqu’ils sont exécutés, « saute » l’UC pour exécuter les instructions de démarrage dans le champ BootCode.

La valeur valide de ce champ est (dans l’ordre d’octets de bas ordre en octets de haut ordre) EBh 76h 90h.

3.1.2 Champ FileSystemName

Le champ FileSystemName doit contenir le nom du système de fichiers sur le volume.

La valeur valide de ce champ est, en caractères ASCII, « EXFAT », qui comprend trois espaces blancs de fin.

3.1.3 Champ MustBezero

Le champ MustBeZero correspond directement à la plage d’octets que le bloc de paramètres BIOS packé consomme sur les volumes FAT12/16/32.

La valeur valide de ce champ est 0, ce qui permet d’empêcher les implémentations FAT12/16/32 de monter par erreur un volume exFAT.

3.1.4 Champ PartitionOffset

Le champ PartitionOffset décrit le décalage du secteur relatif du média de la partition qui héberge le volume exFAT donné. Ce champ permet de sangler le démarrage à partir du volume à l’aide d’INT étendu 13h sur les ordinateurs personnels.

Toutes les valeurs possibles pour ce champ sont valides ; toutefois, la valeur 0 indique que les implémentations doivent ignorer ce champ.

3.1.5 Champ VolumeLength

Le champ VolumeLength décrit la taille du volume exFAT donné dans les secteurs.

La plage de valeurs valide pour ce champ doit être :

  • Au moins 220/ 2BytesPerSectorShift, ce qui garantit que le plus petit volume n’est pas inférieur à 1 Mo

  • Au plus 264- 1, la plus grande valeur que ce champ peut décrire.

    Toutefois, si la taille de la sous-région Espace excédentaire est 0, la plus grande valeur de ce champ est ClusterHeapOffset + (232- 11) *2SectorsPerClusterShift.

3.1.6 Champ FatOffset

Le champ FatOffset décrit le décalage du secteur relatif au volume du premier FAT. Ce champ permet aux implémentations d’aligner le premier fat sur les caractéristiques du support de stockage sous-jacent.

La plage de valeurs valide pour ce champ doit être :

  • Au moins 24, qui comptent pour les secteurs que les régions de démarrage principal et de démarrage de sauvegarde consomment
  • Au maximum ClusterHeapOffset - (FatLength * NumberOfFats), qui compte pour les secteurs que le tas de cluster consomme

3.1.7 Champ FatLength

Le champ FatLength décrit la longueur, dans les secteurs, de chaque table FAT (le volume peut contenir jusqu’à deux FAT).

La plage de valeurs valide pour ce champ doit être :

  • Au moins (ClusterCount + 2) * 22/ 2BytesPerSectorShiftarrondi à l’entier le plus proche, ce qui garantit que chaque FAT dispose d’un espace suffisant pour décrire tous les clusters dans le tas de cluster
  • Au maximum (ClusterHeapOffset - FatOffset) / NumberOfFats arrondi à l’entier le plus proche, ce qui garantit que les fats existent avant le tas de cluster

Ce champ peut contenir une valeur supérieure à sa limite inférieure (comme décrit ci-dessus) pour permettre au second FAT, le cas échéant, d’être aligné sur les caractéristiques du support de stockage sous-jacent. Le contenu de l’espace qui dépasse ce que nécessite la FAT elle-même, le cas échéant, n’est pas défini.

3.1.8 Champ ClusterHeapOffset

Le champ ClusterHeapOffset décrit le décalage du secteur relatif au volume du tas de cluster. Ce champ permet aux implémentations d’aligner le tas de cluster sur les caractéristiques du support de stockage sous-jacent.

La plage de valeurs valide pour ce champ doit être :

  • Au moins FatOffset + FatLength * NumberOfFats, pour tenir compte des secteurs que toutes les régions précédentes consomment
  • Au plus 232- 1 ou VolumeLength - (ClusterCount * 2SectorsPerClusterShift), quel que soit le calcul est inférieur

3.1.9 Champ ClusterCount

Le champ ClusterCount décrit le nombre de clusters que contient le tas de clusters.

La valeur valide pour ce champ doit être la moins élevée de ce qui suit :

  • (VolumeLength - ClusterHeapOffset) / 2SectorsPerClusterShiftarrondi à l’entier le plus proche, qui correspond exactement au nombre de clusters qui peuvent correspondre entre le début du tas de cluster et la fin du volume
  • 232- 11, c’est-à-dire le nombre maximal de clusters qu’un FAT peut décrire

La valeur du champ ClusterCount détermine la taille minimale d’un FAT. Pour éviter des TFF extrêmement volumineuses, les implémentations peuvent contrôler le nombre de clusters dans le tas de clusters en augmentant la taille du cluster (via le champ SectorsPerClusterShift). Cette spécification recommande pas plus de 224 clusters- 2 dans le tas de cluster. Toutefois, les implémentations peuvent gérer des volumes avec jusqu’à 232- 11 clusters dans le tas de cluster.

3.1.10 Champ FirstClusterOfRootDirectory

Le champ FirstClusterOfRootDirectory doit contenir l’index de cluster du premier cluster du répertoire racine. Les implémentations doivent effectuer tous les efforts pour placer le premier cluster du répertoire racine dans le premier cluster non incorrect une fois les clusters consommés par la bitmap d’allocation et la table de cas d’allocation.

La plage de valeurs valide pour ce champ doit être :

  • Au moins 2, l’index du premier cluster dans le tas de cluster
  • Au maximum ClusterCount + 1, index du dernier cluster dans le tas de cluster

3.1.11 Champ VolumeSerialNumber

Le champ VolumeSerialNumber doit contenir un numéro de série unique. Cela aide les implémentations à distinguer les différents volumes exFAT. Les implémentations doivent générer le numéro de série en combinant la date et l’heure de la mise en forme du volume exFAT. Le mécanisme de combinaison de date et d’heure pour former un numéro de série est spécifique à l’implémentation.

Toutes les valeurs possibles pour ce champ sont valides.

3.1.12 Champ FileSystemRevision

Le champ FileSystemRevision décrit les numéros de révision majeurs et mineurs des structures exFAT sur le volume donné.

L’octet à ordre élevé est le numéro de révision principal et l’octet de bas ordre est le numéro de révision mineure. Par exemple, si l’octet de classement élevé contient la valeur 01h et si l’octet de faible ordre contient la valeur 05h, le champ FileSystemRevision décrit le numéro de révision 1.05. De même, si l’octet de classement élevé contient la valeur 0Ah et si l’octet de faible ordre contient la valeur 0Fh, le champ FileSystemRevision décrit le numéro de révision 10.15.

La plage de valeurs valide pour ce champ doit être :

  • Au moins 0 pour l’octet de bas ordre et 1 pour l’octet de haut ordre
  • Au plus 99 pour les octets de bas ordre et 99 pour l’octet de haut ordre

Le numéro de révision d’exFAT décrit cette spécification est 1.00. Les implémentations de cette spécification doivent monter n’importe quel volume exFAT avec le numéro de révision principal 1 et ne monter aucun volume exFAT avec un autre numéro de révision majeur. Les implémentations respectent le numéro de révision mineure et n’effectuent pas d’opérations ni ne créent aucune structure de système de fichiers non décrite dans la spécification correspondante du numéro de révision secondaire donné.

3.1.13 Champ VolumeFlags

Le champ VolumeFlags doit contenir des indicateurs qui indiquent l’état de diverses structures de système de fichiers sur le volume exFAT (voir Tableau 5).

Les implémentations ne doivent pas inclure ce champ lors de l’informatique de sa somme de contrôle principale de démarrage ou de région de démarrage de sauvegarde respective. Lorsque vous faites référence au secteur de démarrage de la sauvegarde, les implémentations traitent ce champ comme obsolète.

Tableau 5 Structure de champ VolumeFlags

nom de champ

offset

(bit)

taille

(bits)

 commentaires
ActiveFat 0 1 Ce champ est obligatoire et section 3.1.13.1 définit son contenu.
VolumeDirty 1 1 Ce champ est obligatoire et section 3.1.13.2 définit son contenu.
Échec des médias 2 1 Ce champ est obligatoire et section 3.1.13.3 définit son contenu.
ClearToZero 3 1 Ce champ est obligatoire et section 3.1.13.4 définit son contenu.
Réservé 4 12 Ce champ est obligatoire et son contenu est réservé.
3.1.13.1 Champ ActiveFat

Le champ ActiveFat décrit les images FAT et Allocation Bitmap actives (et les implémentations doivent être utilisées), comme suit :

  • 0, ce qui signifie que la première image bitmap FAT et First Allocation sont actives
  • 1, ce qui signifie que le second fat et la bitmap d’allocation de seconde sont actifs et est possible uniquement lorsque le champ NumberOfFats contient la valeur 2

Les implémentations doivent considérer les images FAT et Bitmap d’allocation inactives comme obsolètes. Seules les implémentations prenant en charge TexFAT changent les bitmaps fat et d’allocation actives (consultez section 7.1).

3.1.13.2 Champ VolumeDirty

Le champ VolumeDirty décrit si le volume est sale ou non, comme suit :

  • 0, ce qui signifie que le volume est probablement dans un état cohérent
  • 1, ce qui signifie que le volume est probablement dans un état incohérent

Les implémentations doivent définir la valeur de ce champ sur 1 lors de la rencontre d’incohérences de métadonnées du système de fichiers qu’elles ne résolvent pas. Si, lors du montage d’un volume, la valeur de ce champ est 1, seules les implémentations qui résolvent les incohérences de métadonnées du système de fichiers peuvent effacer la valeur de ce champ à 0. Ces implémentations ne doivent effacer la valeur de ce champ qu’à 0 après avoir vérifié que le système de fichiers est dans un état cohérent.

Si, lors du montage d’un volume, la valeur de ce champ est 0, les implémentations doivent définir ce champ sur 1 avant de mettre à jour les métadonnées du système de fichiers et effacer ce champ sur 0 par la suite, comme dans l’ordre d’écriture recommandé décrit dans section 8.1.

3.1.13.3 Champ MediaFailure

Le champ MediaFailure décrit si une implémentation a détecté des échecs multimédias ou non, comme suit :

  • 0, ce qui signifie que le média d’hébergement n’a pas signalé d’échecs ou d’échecs connus sont déjà enregistrés dans le FAT en tant que clusters « incorrects »
  • 1, ce qui signifie que le support d’hébergement a signalé des échecs (c’est-à-dire que les opérations de lecture ou d’écriture ont échoué)

Une implémentation doit définir ce champ sur 1 lorsque :

  1. Le média d’hébergement ne parvient pas à accéder à n’importe quelle région du volume
  2. L’implémentation a épuisé les algorithmes de nouvelle tentative d’accès, le cas échéant

Si, lors du montage d’un volume, la valeur de ce champ est 1, les implémentations qui analysent l’intégralité du volume pour détecter les défaillances multimédias et enregistrent tous les échecs en tant que clusters « incorrects » dans le fat (ou résolvent les échecs multimédias) peuvent effacer la valeur de ce champ à 0.

3.1.13.4 Champ ClearToZero

Le champ ClearToZero n’a pas de signification significative dans cette spécification.

Les valeurs valides pour ce champ sont les suivantes :

  • 0, qui n’a aucune signification particulière
  • 1, ce qui signifie que les implémentations effacent ce champ sur 0 avant de modifier les structures, répertoires ou fichiers du système de fichiers

3.1.14 Champ BytesPerSectorShift

Le champ BytesPerSectorShift décrit les octets par secteur exprimés sous forme de journal2(N), où N correspond au nombre d’octets par secteur. Par exemple, pour 512 octets par secteur, la valeur de ce champ est 9.

La plage de valeurs valide pour ce champ doit être :

  • Au moins 9 (taille du secteur de 512 octets), qui est le plus petit secteur possible pour un volume exFAT
  • Au maximum 12 (taille du secteur de 4 096 octets), qui correspond à la taille de page mémoire des processeurs courants dans les ordinateurs personnels

3.1.15 SectorsPerClusterShift Field

Le champ SectorsPerClusterShift décrit les secteurs par cluster exprimés sous forme de journal2(N), où N est le nombre de secteurs par cluster. Par exemple, pour 8 secteurs par cluster, la valeur de ce champ est 3.

La plage de valeurs valide pour ce champ doit être :

  • Au moins 0 (1 secteur par cluster), qui est le plus petit cluster possible
  • Au maximum 25 - BytesPerSectorShift, qui correspond à une taille de cluster de 32 Mo

3.1.16 Champ NumberOfFats

Le champ NumberOfFats décrit le nombre de faTs et de bitmaps d’allocation que contient le volume.

La plage de valeurs valide pour ce champ doit être :

  • 1, ce qui indique que le volume contient uniquement le premier fichier FAT et la première image bitmap d’allocation
  • 2, qui indique que le volume contient le premier fat, le deuxième fat, la bitmap d’allocation de première et la deuxième image bitmap d’allocation ; cette valeur est valide uniquement pour les volumes TexFAT

3.1.17 Champ DriveSelect

Le champ DriveSelect doit contenir le numéro de lecteur INT 13h étendu, qui aide le sanglage de démarrage à partir de ce volume à l’aide d’INT étendu 13h sur les ordinateurs personnels.

Toutes les valeurs possibles pour ce champ sont valides. Les champs similaires dans les systèmes de fichiers fat précédents contenaient fréquemment la valeur 80h.

3.1.18 Champ PourcentageUtilisation

Le champ PercentInUse décrit le pourcentage de clusters dans le tas de clusters qui sont alloués.

La plage de valeurs valide pour ce champ doit être :

  • Entre 0 et 100 inclus, qui est le pourcentage de clusters alloués dans le tas de cluster, arrondi à l’entier le plus proche
  • Exactement FFh, ce qui indique que le pourcentage de clusters alloués dans le tas de clusters n’est pas disponible

Les implémentations modifient la valeur de ce champ pour refléter les modifications apportées à l’allocation de clusters dans le tas de cluster ou la remplacer par FFh.

Les implémentations ne doivent pas inclure ce champ lors de l’informatique de sa somme de contrôle principale de démarrage ou de région de démarrage de sauvegarde respective. Lorsque vous faites référence au secteur de démarrage de la sauvegarde, les implémentations traitent ce champ comme obsolète.

3.1.19 Champ BootCode

Le champ BootCode doit contenir des instructions de sangle de démarrage. Les implémentations peuvent remplir ce champ avec les instructions du processeur nécessaires pour le démarrage d’un système informatique. Les implémentations qui ne fournissent pas d’instructions de sanglage de démarrage doivent initialiser chaque octet dans ce champ sur F4h (l’instruction d’arrêt pour les processeurs communs dans les ordinateurs personnels) dans le cadre de leur opération de format.

3.1.20 Champ BootSignature

Le champ BootSignature doit décrire si l’intention d’un secteur donné est qu’il s’agit d’un secteur de démarrage ou non.

La valeur valide de ce champ est AA55h. Toute autre valeur de ce champ invalide son secteur de démarrage respectif. Les implémentations doivent vérifier le contenu de ce champ avant de dépendre d’un autre champ dans son secteur de démarrage respectif.

3.2 Secteurs de démarrage étendu principal et de sauvegarde sous-régions

Chaque secteur des principaux secteurs de démarrage étendu a la même structure ; toutefois, chaque secteur peut contenir des instructions distinctes de sangles de démarrage (voir le tableau 6). Les agents de sanglage de démarrage, tels que les instructions de sanglage de démarrage dans le secteur de démarrage principal, les implémentations de BIOS alternatives ou le microprogramme d’un système incorporé, peuvent charger ces secteurs et exécuter les instructions qu’ils contiennent.

Les secteurs de démarrage étendu de sauvegarde sont une sauvegarde des principaux secteurs de démarrage étendu et ont la même structure (voir Tableau 6).

Avant d’exécuter les instructions des secteurs de démarrage étendu principal ou de sauvegarde, les implémentations doivent vérifier leur contenu en s’assurant que le champ ExtendedBootSignature de chaque secteur contient sa valeur prescrite.

Bien que l’opération de format initiale initialise le contenu des secteurs de démarrage étendu principal et de sauvegarde, les implémentations peuvent mettre à jour ces secteurs (et mettent également à jour leur somme de contrôle de démarrage respective) si nécessaire.

tableau 6 structure du secteur de démarrage étendu

nom de champ

offset

(octets)

taille

(octets)

 commentaires
ExtendedBootCode 0 2BytesPerSectorShift – 4

Ce champ est obligatoire et section 3.2.1 définit son contenu.

Remarque : les secteurs de démarrage principal et de sauvegarde contiennent tous deux le champ BytesPerSectorShift.
ExtendedBootSignature 2OctetsPerSectorShift – 4 4

Ce champ est obligatoire et section 3.2.2 définit son contenu.

Remarque : les secteurs de démarrage principal et de sauvegarde contiennent tous deux le champ BytesPerSectorShift.

3.2.1 Champ ExtendedBootCode

Le champ ExtendedBootCode doit contenir des instructions de sangle de démarrage. Les implémentations peuvent remplir ce champ avec les instructions du processeur nécessaires pour le démarrage d’un système informatique. Les implémentations qui ne fournissent pas d’instructions de sanglage de démarrage doivent initialiser chaque octet dans ce champ à 00h dans le cadre de leur opération de mise en forme.

3.2.2 Champ ExtendedBootSignature

Le champ ExtendedBootSignature doit décrire si l’intention du secteur donné est qu’il s’agit d’un secteur de démarrage étendu ou non.

La valeur valide de ce champ est AA550000h. Toute autre valeur de ce champ invalide son secteur de démarrage principal ou de sauvegarde respectif. Les implémentations doivent vérifier le contenu de ce champ avant de dépendre d’un autre champ dans son secteur de démarrage étendu respectif.

3.3 Sous-régions principales et de sauvegarde des paramètres OEM

La sous-région Paramètres OEM principal contient dix structures de paramètres qui peuvent contenir des informations spécifiques au fabricant (voir Tableau 7). Chacune des dix structures de paramètres dérive du modèle Paramètres génériques (voir section 3.3.2). Les fabricants peuvent dériver leurs propres structures de paramètres personnalisés à partir du modèle Paramètres génériques. Cette spécification définit elle-même deux structures de paramètres : Paramètres Null (voir Section 3.3.3) et Paramètres Flash (voir Section 3.3.4).

Les paramètres OEM de sauvegarde sont une sauvegarde des paramètres OEM principaux et ont la même structure (voir Tableau 7).

Avant d’utiliser le contenu des paramètres OEM principal ou de sauvegarde, les implémentations vérifient leur contenu en validant leur somme de contrôle de démarrage respective.

Les fabricants doivent remplir les paramètres OEM Main et Backup avec leurs propres structures de paramètres personnalisées, le cas échéant, et d’autres structures de paramètres. Les opérations de format suivantes conservent le contenu des paramètres OEM principal et de sauvegarde.

Les implémentations peuvent mettre à jour les paramètres OEM principaux et de sauvegarde en fonction des besoins (et doivent également mettre à jour leur somme de contrôle de démarrage respective).

Tableau 7, structure des paramètres OEM

nom de champ

offset

(octets)

taille

(octets)

 commentaires
Paramètres[0] 0 48 Ce champ est obligatoire et section 3.3.1 définit son contenu.

.

.

.

.

.

.

.

.

.

.

.

.
Paramètres[9] 432 48 Ce champ est obligatoire et section 3.3.1 définit son contenu.
Réservé 480 2BytesPerSectorShift – 480

Ce champ est obligatoire et son contenu est réservé.

Remarque : les secteurs de démarrage principal et de sauvegarde contiennent tous deux le champ BytesPerSectorShift.

3.3.1 Paramètres[0] ... Paramètres[9]

Chaque champ Paramètres de ce tableau contient une structure de paramètres, qui dérive du modèle Paramètres génériques (voir Section 3.3.2). Tout champ Paramètres inutilisés doit être décrit comme contenant une structure de paramètres Null (voir section 3.3.3).

3.3.2 Modèle de paramètres génériques

Le modèle Paramètres génériques fournit la définition de base d’une structure de paramètres (voir Tableau 8). Toutes les structures de paramètres dérivent de ce modèle. La prise en charge de ce modèle de paramètres génériques est obligatoire.

modèle de paramètres génériques tableau 8

nom de champ

offset

(octets)

taille

(octets)

 commentaires
ParametersGuid 0 16 Ce champ est obligatoire et section 3.3.2.1 définit son contenu.
CustomDefined 16 32 Ce champ est obligatoire et les structures dérivées de ce modèle définissent son contenu.
3.3.2.1 Champ ParametersGuid

Le champ ParametersGuid décrit un GUID, qui détermine la disposition du reste de la structure de paramètres donnée.

Toutes les valeurs possibles pour ce champ sont valides ; Toutefois, les fabricants doivent utiliser un outil de génération GUID, tel que GuidGen.exe, pour sélectionner un GUID lors de la dérivation de structures de paramètres personnalisées à partir de ce modèle.

3.3.3 Paramètres Null

La structure paramètres Null dérive du modèle Paramètres génériques (voir section 3.3.2) et décrit un champ Paramètres inutilisés (voir Tableau 9). Lors de la création ou de la mise à jour de la structure des paramètres OEM, les implémentations remplissent les champs Paramètres inutilisés avec la structure Paramètres Null. En outre, lors de la création ou de la mise à jour de la structure des paramètres OEM, les implémentations doivent consolider les structures de paramètres Null à la fin du tableau, laissant ainsi toutes les autres structures de paramètres au début de la structure paramètres OEM.

La prise en charge de la structure des paramètres Null est obligatoire.

table 9 de la structure des paramètres Null

nom de champ

offset

(octets)

taille

(octets)

 commentaires
ParametersGuid 0 16 Ce champ est obligatoire et section 3.3.3.1 définit son contenu.
Réservé 16 32 Ce champ est obligatoire et son contenu est réservé.
3.3.3.1 Champ ParametersGuid

Le champ ParametersGuid doit être conforme à la définition fournie par le modèle Paramètres génériques (voir section 3.3.2.1).

La valeur valide pour ce champ, en notation GUID, est {00000000-0000-0000-0000-000000000000}.

3.3.4 Paramètres flash

La structure des paramètres Flash dérive du modèle Paramètres génériques (voir Section 3.3.2) et contient des paramètres pour le support flash (voir Tableau 10). Les fabricants d’appareils de stockage flash peuvent remplir un champ Paramètres (de préférence le champ Parameters[0] ) avec cette structure de paramètres. Les implémentations peuvent utiliser les informations de la structure Paramètres Flash pour optimiser les opérations d’accès pendant les lectures/écritures et pour l’alignement des structures de système de fichiers pendant la mise en forme du média.

La prise en charge de la structure des paramètres Flash est facultative.

tableau 10 de la structure des paramètres flash

nom de champ

offset

(octets)

taille

(octets)

 commentaires
ParametersGuid 0 16 Ce champ est obligatoire et section 3.3.4.1 définit son contenu.
EraseBlockSize 16 4 Ce champ est obligatoire et section 3.3.4.2 définit son contenu.
Pagesize 20 4 Ce champ est obligatoire et section 3.3.4.3 définit son contenu.
Secteurs de réserve Vingt-quatre 4 Ce champ est obligatoire et section 3.3.4.4 définit son contenu.
Temps d'Accès Aléatoire 28 4 Ce champ est obligatoire et section 3.3.4.5 définit son contenu.
Temps de Programmation 32 4 Ce champ est obligatoire et section 3.3.4.6 définit son contenu.
ReadCycle 36 4 Ce champ est obligatoire et section 3.3.4.7 définit son contenu.
WriteCycle 40 4 Ce champ est obligatoire et section 3.3.4.8 définit son contenu.
Réservé 44 4 Ce champ est obligatoire et son contenu est réservé.

Toutes les valeurs possibles pour tous les champs Paramètres Flash, à l’exception du champ ParametersGuid, sont valides. Toutefois, la valeur 0 indique que le champ n’a pas de signification (les implémentations ignorent le champ donné).

3.3.4.1 Champ ParametersGuid

Le champ ParametersGuid doit être conforme à la définition fournie dans le modèle Paramètres génériques (voir section 3.3.2.1).

La valeur valide pour ce champ, en notation GUID, est {0A0C7E46-3399-4021-90C8-FA6D389C4BA2}.

3.3.4.2 EraseBlockSize Field

Le champ EraseBlockSize décrit la taille, en octets, du bloc d’effacement du média flash.

3.3.4.3 Champ PageSize

Le champ PageSize décrit la taille, en octets de la page du média flash.

3.3.4.4 Champ SpareSectors

Le champ SpareSectors décrit le nombre de secteurs que le média flash a disponibles pour ses opérations internes d’épargne.

3.3.4.5 Champ RandomAccessTime

Le champ RandomAccessTime décrit le temps d’accès aléatoire moyen du média flash, en nanosecondes.

3.3.4.6 Champ ProgrammingTime

Le champ ProgrammingTime décrit le temps de programmation moyen du média flash, en nanosecondes.

3.3.4.7 Champ ReadCycle

Le champ ReadCycle décrit le temps moyen de cycle de lecture du média flash, en nanosecondes.

3.3.4.8 Champ WriteCycle

Le champ WriteCycle décrit le temps moyen de cycle d’écriture, en nanosecondes.

3.4 Sous-régions de somme de contrôle de démarrage principale et de sauvegarde

Les sommes de contrôle de démarrage principales et de sauvegarde contiennent chacune un modèle répétitif de la somme de contrôle de quatre octets du contenu de toutes les autres sous-régions de leurs régions de démarrage respectives. Le calcul de somme de contrôle n’inclut pas les champs VolumeFlags et PercentInUse dans leur secteur de démarrage respectif (voir Figure 1). Le modèle répétitif de la somme de contrôle de quatre octets remplit sa sous-région de somme de contrôle de démarrage respective du début à la fin de la sous-région.

Avant d’utiliser le contenu de l’une des autres sous-régions dans les régions de démarrage principal ou de sauvegarde, les implémentations vérifient leur contenu en validant leur somme de contrôle de démarrage respective.

Bien que l’opération de format initiale remplisse les sommes de contrôle de démarrage principales et de sauvegarde avec le modèle de somme de contrôle répétée, les implémentations mettent à jour ces secteurs à mesure que le contenu des autres secteurs de leurs régions de démarrage respectives change.

Figure 1 Calcul de somme de contrôle de démarrage

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 Région de la table d’allocation de fichiers

La région FAT (File Allocation Table) peut contenir jusqu’à deux FAT, une dans la première sous-région FAT et une autre dans la deuxième sous-région FAT. Le champ NumberOfFats décrit le nombre de fats que contient cette région. Les valeurs valides pour le champ NumberOfFats sont 1 et 2. Par conséquent, la sous-région FIRST FAT contient toujours un FAT. Si le champ NumberOfFats est deux, la deuxième sous-région FAT contient également une valeur FAT.

Le champ ActiveFat du champ VolumeFlags décrit le fat actif. Seul le champ VolumeFlags du secteur de démarrage principal est actif. Les implémentations doivent traiter le FAT qui n’est pas actif comme obsolète. L’utilisation des fat inactifs et le basculement entre les faTs est spécifique à l’implémentation.

4.1 Première et deuxième sous-régions FAT

Un fat décrit les chaînes de cluster dans le tas de cluster (voir Tableau 11). Une chaîne de cluster est une série de clusters qui fournissent de l’espace pour enregistrer le contenu des fichiers, des répertoires et d’autres structures de système de fichiers. Un FAT représente une chaîne de cluster sous la forme d’une liste d’index de cluster liée de manièreing. À l’exception des deux premières entrées, chaque entrée d’un fat représente exactement un cluster.

structure de table d’allocation de fichiers tableau 11

nom de champ

offset

(octets)

taille

(octets)

 commentaires
FatEntry[0] 0 4 Ce champ est obligatoire et section 4.1.1 définit son contenu.
FatEntry[1] 4 4 Ce champ est obligatoire et section 4.1.2 définit son contenu.
FatEntry[2] 8 4 Ce champ est obligatoire et section 4.1.3 définit son contenu.

.

.

.

.

.

.

.

.

.

.

.

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

Ce champ est obligatoire et section 4.1.3 définit son contenu.

ClusterCount + 1 ne peut jamais dépasser FFFFFFF6h.

Remarque : les secteurs de démarrage principal et de sauvegarde contiennent tous deux le champ ClusterCount.
ExcessSpace (ClusterCount + 2) * 4 (FatLength * 2BytesPerSectorShift) – ((ClusterCount + 2) * 4)

Ce champ est obligatoire et son contenu, le cas échéant, ne sont pas définis.

Remarque : les secteurs de démarrage principal et de sauvegarde contiennent les champs ClusterCount, FatLength et BytesPerSectorShift.

4.1.1 FatEntry[0] Champ

Le champ FatEntry[0] décrit le type de média dans le premier octet (octet de l’ordre le plus bas) et doit contenir FFh dans les trois octets restants.

Le type de média (le premier octet) doit être F8h.

4.1.2 FatEntry[1] Champ

Le champ FatEntry[1] existe uniquement en raison de la précédence historique et ne décrit rien d’intéressant.

La valeur valide de ce champ est FFFFFFFFh. Les implémentations initialisent ce champ à sa valeur prescrite et ne doivent pas utiliser ce champ à des fins quelconques. Les implémentations ne doivent pas interpréter ce champ et conserver leur contenu entre les opérations qui modifient les champs environnants.

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

Chaque champ FatEntry de ce tableau doit représenter un cluster dans le tas de cluster. FatEntry[2] représente le premier cluster dans le tas de cluster et FatEntry[ClusterCount+1] représente le dernier cluster du tas de cluster.

La plage de valeurs valide pour ces champs doit être :

  • Entre 2 et ClusterCount + 1, inclus, qui pointe vers la prochaine FatEntry dans la chaîne de cluster donnée ; le FatEntry donné ne pointe vers aucune FatEntry qui la précède dans la chaîne de cluster donnée
  • Exactement FFFFFFF7h, qui marque le cluster correspondant de FatEntry donné comme « mauvais »
  • Exactement FFFFFFFFh, qui marque le cluster correspondant de FatEntry donné comme dernier cluster d’une chaîne de cluster ; il s’agit de la seule valeur valide pour le dernier FatEntry d’une chaîne de cluster donnée

5 Région de données

La région de données contient le tas de clusters, qui fournit de l’espace managé pour les structures, répertoires et fichiers du système de fichiers.

5.1 Sous-région de tas de cluster

La structure du tas de cluster est très simple (voir Tableau 12) ; chaque série consécutive de secteurs décrit un cluster, comme le champ SectorsPerClusterShift définit. Il est important de noter que le premier cluster du tas de cluster a l’index deux, qui correspond directement à l’index de FatEntry[2].

Dans un volume exFAT, une bitmap d’allocation (voir section 7.1.5) conserve l’enregistrement de l’état d’allocation de tous les clusters. Il s’agit d’une différence significative par rapport aux prédécesseurs d’exFAT (FAT12, FAT16 et FAT32), dans lesquelles un FAT a conservé un enregistrement de l’état d’allocation de tous les clusters dans le tas de cluster.

Table 12 de structure de tas de cluster

nom de champ

offset

(secteur)

taille

(secteurs)

 commentaires
Cluster[2] ClusterHeapOffset 2 secteursPerClusterShift

Ce champ est obligatoire et section 5.1.1 définit son contenu.

Remarque : les secteurs de démarrage principal et de sauvegarde contiennent les champs ClusterHeapOffset et SectorsPerClusterShift.

.

.

.

.

.

.

.

.

.

.

.

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

Ce champ est obligatoire et section 5.1.1 définit son contenu.

Remarque : les secteurs de démarrage principal et de sauvegarde contiennent les champs ClusterCount, ClusterHeapOffset et SectorsPerClusterShift.

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

Chaque champ cluster de ce tableau est une série de secteurs contigus, dont la taille est définie par le champ SectorsPerClusterShift.

6 Structure de répertoires

Le système de fichiers exFAT utilise une approche d’arborescence de répertoires pour gérer les structures et fichiers du système de fichiers qui existent dans le tas de cluster. Les répertoires ont une relation un-à-plusieurs entre parent et enfant dans l’arborescence d’annuaires.

Le répertoire auquel le champ FirstClusterOfRootDirectory fait référence est la racine de l’arborescence de répertoires. Tous les autres répertoires descendent du répertoire racine de manière singly-linked.

Chaque répertoire se compose d’une série d’entrées de répertoire (voir Tableau 13).

Une ou plusieurs entrées de répertoire se combinent dans un jeu d’entrées d’annuaire qui décrit quelque chose d’intéressant, tel qu’une structure de système de fichiers, un sous-répertoire ou un fichier.

table 13, structure de répertoires

nom de champ

offset

(octets)

taille

(octets)

 commentaires
DirectoryEntry[0] 0 32 Ce champ est obligatoire et section 6.1 définit son contenu.

.

.

.

.

.

.

.

.

.

.

.

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

Ce champ est obligatoire et section 6.1 définit son contenu.

N, le nombre de champs DirectoryEntry est la taille, en octets, de la chaîne de cluster qui contient le répertoire donné, divisé par la taille d’un champ DirectoryEntry, 32 octets.

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

Chaque champ DirectoryEntry de ce tableau dérive du modèle Generic DirectoryEntry (voir section 6.2).

6.2 Modèle DirectoryEntry générique

Le modèle Generic DirectoryEntry fournit la définition de base des entrées d’annuaire (voir Tableau 14). Toutes les structures d’entrée d’annuaire dérivent de ce modèle et seules les structures d’entrée de répertoire définies par Microsoft sont valides (exFAT ne dispose pas de dispositions pour les structures d’entrée de répertoire définies par le fabricant, sauf définies dans section 7.8 et section 7.9). La possibilité d’interpréter le modèle Generic DirectoryEntry est obligatoire.

tableau 14 de modèle DirectoryEntry générique

nom de champ

offset

(octets)

taille

(octets)

 commentaires
Type d'entrée 0 1 Ce champ est obligatoire et section 6.2.1 définit son contenu.
CustomDefined 1 19 Ce champ est obligatoire et les structures dérivées de ce modèle peuvent définir son contenu.
FirstCluster 20 4 Ce champ est obligatoire et section 6.2.2 définit son contenu.
LongueurDesDonnées Vingt-quatre 8 Ce champ est obligatoire et section 6.2.3 définit son contenu.

6.2.1 Champ EntryType

Le champ EntryType a trois modes d’utilisation que la valeur du champ définit (voir la liste ci-dessous).

  • 00h, qui est un marqueur de fin de répertoire et les conditions suivantes s’appliquent :
    • Tous les autres champs de l’annuaire donné sont en fait réservés
    • Toutes les entrées de répertoire suivantes dans le répertoire donné sont également des marqueurs de fin de répertoire
    • Les marqueurs de fin de répertoire ne sont valides qu’en dehors des jeux d’entrées d’annuaire
    • Les implémentations peuvent remplacer les marqueurs de fin de répertoire si nécessaire
  • Entre 01h et 7Fh inclus, un marqueur d'entrée d'annuaire inutilisé est présent, et les conditions suivantes s'appliquent :
    • Tous les autres champs dans directoryEntry donnés ne sont pas définis
    • Les entrées d’annuaire inutilisées ne sont valides qu’en dehors des jeux d’entrées d’annuaire
    • Les implémentations peuvent remplacer les entrées d’annuaire inutilisées si nécessaire
    • Cette plage de valeurs correspond au champ InUse (voir Section 6.2.1.4) contenant la valeur 0
  • Entre 81h et FFh inclus, cela représente une entrée de répertoire standard et les conditions suivantes s'appliquent :
    • Le contenu du champ EntryType (voir Tableau 15) détermine la disposition du reste de la structure DirectoryEntry
    • Cette plage de valeurs, et uniquement cette plage de valeurs, sont valides à l’intérieur d’un jeu d’entrées de répertoire
    • Cette plage de valeurs correspond directement au champ InUse (voir Section 6.2.1.4) contenant la valeur 1

Pour empêcher les modifications apportées au champ InUse (voir section 6.2.1.4) entraînant une erreur résultant d’un marqueur de fin de répertoire, la valeur 80h n’est pas valide.

tableau 15, structure de champ EntryType générique

nom de champ

offset

(bit)

taille

(bits)

 commentaires
TypeCode 0 5 Ce champ est obligatoire et section 6.2.1.1 définit son contenu.
TypeImportance 5 1 Ce champ est obligatoire et la section section 6.2.1.2 définit son contenu.
TypeCatégorie 6 1 Ce champ est obligatoire et section 6.2.1.3 définit son contenu.
InUse 7 1 Ce champ est obligatoire et section 6.2.1.4 définit son contenu.
6.2.1.1 Champ TypeCode

Le champ TypeCode décrit partiellement le type spécifique de l’entrée de répertoire donnée. Ce champ, ainsi que les champs TypeImportance et TypeCategory (voir section 6.2.1.2 et section 6.2.1.3, respectivement) identifient de manière unique le type de l’entrée de répertoire donnée.

Toutes les valeurs possibles de ce champ sont valides, sauf si les champs TypeImportance et TypeCategory contiennent toutes les deux la valeur 0 ; dans ce cas, la valeur 0 n’est pas valide pour ce champ.

6.2.1.2 Champ TypeImportance

Le champ TypeImportance décrit l’importance de l’entrée de répertoire donnée.

Les valeurs valides pour ce champ doivent être les suivantes :

  • 0, ce qui signifie que l’entrée de répertoire donnée est critique (voir section 6.3.1.2.1 et section 6.4.1.2.1 pour les entrées de répertoire secondaire primaire et critique critiques, respectivement)
  • 1, ce qui signifie que l’entrée d’annuaire donnée est bénigne (voir section 6.3.1.2.2 et section 6.4.1.2.2 pour les entrées de répertoire secondaire primaire et bénin, respectivement)
6.2.1.3 Champ TypeCategory

Le champ TypeCategory décrit la catégorie de l’entrée de répertoire donnée.

Les valeurs valides pour ce champ doivent être les suivantes :

  • 0, ce qui signifie que l’entrée de répertoire donnée est primaire (voir section 6.3)
  • 1, ce qui signifie que l’entrée de répertoire donnée est secondaire (voir section 6.4)
6.2.1.4 Champ InUse

Le champ InUse décrit si l’entrée d’annuaire donnée en cours d’utilisation ou non.

Les valeurs valides pour ce champ doivent être les suivantes :

  • 0, ce qui signifie que l’entrée de répertoire donnée n’est pas utilisée ; cela signifie que la structure donnée est en fait une entrée d’annuaire inutilisée
  • 1, ce qui signifie que l’entrée de répertoire donnée est en cours d’utilisation ; cela signifie que la structure donnée est une entrée de répertoire standard

6.2.2 Champ FirstCluster

Le champ FirstCluster doit contenir l’index du premier cluster d’une allocation dans le tas de cluster associé à l’entrée de répertoire donnée.

La plage de valeurs valide pour ce champ doit être :

  • Exactement 0, ce qui signifie qu’aucune allocation de cluster n’existe
  • Entre 2 et ClusterCount + 1, qui est la plage d’index de cluster valides

Les structures qui dérivent de ce modèle peuvent redéfinir les champs FirstCluster et DataLength, si une allocation de cluster n’est pas compatible avec la structure dérivée.

6.2.3 Champ DataLength

Le champ DataLength décrit la taille, en octets, des données que contient l’allocation de cluster associée.

La plage de valeurs valide pour ce champ est la suivante :

  • Au moins 0 ; si le champ FirstCluster contient la valeur 0, la seule valeur valide de ce champ est 0
  • Au plus ClusterCount * 2SectorsPerClusterShift* 2BytesPerSectorShift

Les structures qui dérivent de ce modèle peuvent redéfinir les champs FirstCluster et DataLength, si une allocation de cluster n’est pas possible pour la structure dérivée.

6.3 Modèle d’annuaire principal générique

La première entrée de répertoire dans un jeu d’entrées d’annuaire doit être une entrée de répertoire primaire. Toutes les entrées de répertoire suivantes, le cas échéant, dans le jeu d’entrées d’annuaire doivent être des entrées de répertoire secondaire (voir section 6.4).

La possibilité d’interpréter le modèle Primary DirectoryEntry générique est obligatoire.

Toutes les structures d’entrée de répertoire primaire dérivent du modèle Generic Primary DirectoryEntry (voir Tableau 16), qui dérive du modèle Generic DirectoryEntry (voir Section 6.2).

tableau 16 modèle Primary DirectoryEntry générique

nom de champ

offset

(octets)

taille

(octets)

 commentaires
Type d'entrée 0 1 Ce champ est obligatoire et section 6.3.1 définit son contenu.
CompteSecondaire 1 1 Ce champ est obligatoire et section 6.3.2 définit son contenu.
SetChecksum 2 2 Ce champ est obligatoire et section 6.3.3 définit son contenu.
DrapeauxGénérauxPrimaires 4 2 Ce champ est obligatoire et section 6.3.4 définit son contenu.
CustomDefined 6 14 Ce champ est obligatoire et les structures dérivées de ce modèle définissent son contenu.
FirstCluster 20 4 Ce champ est obligatoire et section 6.3.5 définit son contenu.
LongueurDonnees Vingt-quatre 8 Ce champ est obligatoire et section 6.3.6 définit son contenu.

6.3.1 Champ EntryType

Le champ EntryType doit être conforme à la définition fournie dans le modèle Generic DirectoryEntry (voir section 6.2.1).

6.3.1.1 Champ TypeCode

Le champ TypeCode doit être conforme à la définition fournie dans le modèle Generic DirectoryEntry (voir section 6.2.1.1).

6.3.1.2 Champ TypeImportance

Le champ TypeImportance doit être conforme à la définition fournie dans le modèle Generic DirectoryEntry (voir section 6.2.1.2).

6.3.1.2.1 Entrées de répertoire principal critiques

Les entrées de répertoire principal critiques contiennent des informations essentielles à la gestion appropriée d’un volume exFAT. Seul le répertoire racine contient des entrées de répertoire primaire critiques (les entrées de répertoire de fichiers sont une exception, consultez section 7.4).

La définition des entrées de répertoire principal critiques est corrélée au numéro de révision exFAT principal. Les implémentations prennent en charge toutes les entrées de répertoire principal critiques et enregistrent uniquement les structures d’entrée de répertoire primaire critiques définies par cette spécification.

6.3.1.2.2 Entrées de répertoire principal bénins

Les entrées de répertoire principal bénignes contiennent des informations supplémentaires qui peuvent être utiles pour la gestion d’un volume exFAT. Tout répertoire peut contenir des entrées de répertoire primaire sans gravité.

La définition d’entrées de répertoire principal sans gravité est corrélée au numéro de révision exFAT mineur. La prise en charge de n’importe quelle entrée de répertoire primaire sans gravité, cette spécification ou toute spécification ultérieure, est facultative. Une entrée de répertoire primaire non reconnue non reconnue restitue l’ensemble de l’entrée de répertoire définie comme non reconnue (au-delà de la définition des modèles d’entrée de répertoire applicables).

6.3.1.3 Champ TypeCategory

Le champ TypeCategory doit être conforme à la définition fournie dans le modèle Generic DirectoryEntry (voir section 6.2.1.3).

Pour ce modèle, la valeur valide de ce champ doit être 0.

6.3.1.4 Champ InUse

Le champ InUse doit être conforme à la définition fournie dans le modèle Generic DirectoryEntry (voir section 6.2.1.4).

6.3.2 Champ SecondaryCount

Le champ SecondaryCount décrit le nombre d’entrées de répertoire secondaire qui suivent immédiatement l’entrée de répertoire primaire donnée. Ces entrées de répertoire secondaire, ainsi que l’entrée de répertoire primaire donnée, comprennent le jeu d’entrées d’annuaire.

La plage de valeurs valide pour ce champ doit être :

  • Au moins 0, ce qui signifie que cette entrée de répertoire primaire est la seule entrée dans le jeu d’entrées d’annuaire
  • Au maximum 255, ce qui signifie que les 255 entrées de répertoire suivantes et cette entrée de répertoire primaire comprennent le jeu d’entrées d’annuaire

Les structures d’entrée de répertoire principal critiques qui dérivent de ce modèle peuvent redéfinir les champs SecondaryCount et SetChecksum.

6.3.3 Champ SetChecksum

Le champ SetChecksum doit contenir la somme de contrôle de toutes les entrées d’annuaire dans le jeu d’entrées d’annuaire donné. Toutefois, la somme de contrôle exclut ce champ (voir Figure 2). Les implémentations vérifient que le contenu de ce champ est valide avant d’utiliser toute autre entrée de répertoire dans le jeu d’entrées d’annuaire donné.

Les structures d’entrée de répertoire principal critiques qui dérivent de ce modèle peuvent redéfinir les champs SecondaryCount et SetChecksum.

Figure 2 Calcul de l'EntrySetChecksum

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 Champ IndicateursPrimairesGénéraux

Le champ GeneralPrimaryFlags contient des indicateurs (voir Tableau 17).

Les structures d’entrée de répertoire principal critiques qui dérivent de ce modèle peuvent redéfinir ce champ.

Tableau 17 GénéralPrimaryFlags générique

nom de champ

offset

(bit)

taille

(bits)

 commentaires
AllocationPossible 0 1 Ce champ est obligatoire et section 6.3.4.1 définit son contenu.
NoFatChain 1 1 Ce champ est obligatoire et section 6.3.4.2 définit son contenu.
CustomDefined 2 14 Ce champ est obligatoire et les structures dérivées de ce modèle peuvent définir ce champ.
6.3.4.1 Champ AllocationPossible

Le champ AllocationPossible indique si une allocation dans le tas de cluster est possible pour l’entrée de répertoire donnée.

Les valeurs valides pour ce champ doivent être les suivantes :

  • 0, ce qui signifie qu’une allocation associée de clusters n’est pas possible et que les champs FirstCluster et DataLength ne sont pas définis (les structures dérivées de ce modèle peuvent redéfinir ces champs)
  • 1, ce qui signifie qu’une allocation associée de clusters est possible et que les champs FirstCluster et DataLength sont définis comme définis
6.3.4.2 Champ NoFatChain

Le champ NoFatChain indique si le fat actif décrit ou non la chaîne de cluster de l’allocation donnée.

Les valeurs valides pour ce champ doivent être les suivantes :

  • 0, ce qui signifie que les entrées FAT correspondantes pour la chaîne de cluster de l’allocation sont valides et les implémentations doivent les interpréter ; si le champ AllocationPossible contient la valeur 0, ou si le champ AllocationPossible contient la valeur 1 et le champ FirstCluster contient la valeur 0, la seule valeur valide de ce champ est 0.
  • 1, ce qui signifie que l’allocation associée est une série contiguë de clusters ; les entrées FAT correspondantes pour les clusters ne sont pas valides et les implémentations ne les interprètent pas ; les implémentations peuvent utiliser l’équation suivante pour calculer la taille de l’allocation associée : DataLength / (2SectorsPerClusterShift* 2BytesPerSectorShift) arrondi à l’entier le plus proche

Si les structures d’entrée de répertoire principal critiques qui dérivent de ce modèle redéfinissent le champ GeneralPrimaryFlags, les entrées FAT correspondantes pour la chaîne de cluster d’une allocation associée sont valides.

6.3.5 Champ FirstCluster

Le champ FirstCluster doit être conforme à la définition fournie dans le modèle Generic DirectoryEntry (voir section 6.2.2).

Si le bit NoFatChain est 1, FirstCluster doit pointer vers un cluster valide dans le tas de cluster.

Les structures d’entrée de répertoire principal critiques qui dérivent de ce modèle peuvent redéfinir les champs FirstCluster et DataLength. D’autres structures dérivées de ce modèle peuvent redéfinir les champs FirstCluster et DataLength uniquement si le champ AllocationPossible contient la valeur 0.

6.3.6 Champ DataLength

Le champ DataLength doit être conforme à la définition fournie dans le modèle Generic DirectoryEntry (voir section 6.2.3).

Si le bit NoFatChain est 1, DataLength ne doit pas être égal à zéro. Si le champ FirstCluster est égal à zéro, DataLength doit également être égal à zéro.

Les structures d’entrée de répertoire principal critiques qui dérivent de ce modèle peuvent redéfinir les champs FirstCluster et DataLength. D’autres structures dérivées de ce modèle peuvent redéfinir les champs FirstCluster et DataLength uniquement si le champ AllocationPossible contient la valeur 0.

6.4 Modèle d’annuaire secondaire générique

L’objectif central des entrées de répertoire secondaire est de fournir des informations supplémentaires sur un jeu d’entrées d’annuaire. La possibilité d’interpréter le modèle Generic Secondary DirectoryEntry est obligatoire.

La définition des entrées de répertoire secondaire critique et bénin est corrélée au numéro de révision exFAT mineur. La prise en charge de toute entrée de répertoire secondaire critique ou bénin que cette spécification, ou les spécifications ultérieures, est facultative.

Toutes les structures d’entrée de répertoire secondaire dérivent du modèle DirectoryEntry secondaire générique (voir Tableau 18), qui dérive du modèle Generic DirectoryEntry (voir Section 6.2).

tableau 18 modèle DirectoryEntry secondaire générique

nom de champ

offset

(octets)

taille

(octets)

 commentaires
Type d'entrée 0 1 Ce champ est obligatoire et la section section 6.4.1 définit son contenu.
GeneralSecondaryFlags 1 1 Ce champ est obligatoire et section 6.4.2 définit son contenu.
CustomDefined 2 18 Ce champ est obligatoire et les structures dérivées de ce modèle définissent son contenu.
FirstCluster 20 4 Ce champ est obligatoire et section 6.4.3 définit son contenu.
LongueurDonnees Vingt-quatre 8 Ce champ est obligatoire et section 6.4.4 définit son contenu.

6.4.1 Champ EntryType

Le champ EntryType doit être conforme à la définition fournie dans le modèle Generic DirectoryEntry (voir section 6.2.1)

6.4.1.1 Champ TypeCode

Le champ TypeCode doit être conforme à la définition fournie dans le modèle Generic DirectoryEntry (voir section 6.2.1.1).

6.4.1.2 Champ TypeImportance

Le champ TypeImportance doit être conforme à la définition fournie dans le modèle Generic DirectoryEntry (voir section 6.2.1.2).

6.4.1.2.1 Entrées de répertoire secondaire critique

Les entrées de répertoire secondaire critiques contiennent des informations essentielles à la gestion appropriée de son jeu d’entrées d’annuaire contenant. Bien que la prise en charge d’une entrée de répertoire secondaire critique spécifique soit facultative, une entrée de répertoire critique non reconnue affiche l’ensemble de l’entrée de répertoire définie comme non reconnue (au-delà de la définition des modèles d’entrée de répertoire applicables).

Toutefois, si un jeu d’entrées d’annuaire contient au moins une entrée de répertoire secondaire critique qu’une implémentation ne reconnaît pas, l’implémentation interprète au maximum les modèles des entrées de répertoire dans le jeu d’entrées d’annuaire et non les données associées à une entrée de répertoire dans le jeu d’entrées de répertoire contient (les entrées de répertoire de fichiers sont une exception, voir section 7.4).

6.4.1.2.2 Entrées de répertoire secondaire bénin

Les entrées de répertoire secondaire bénignes contiennent des informations supplémentaires qui peuvent être utiles pour gérer son jeu d’entrées d’annuaire contenant. La prise en charge de toute entrée de répertoire secondaire bénigne spécifique est facultative. Les entrées de répertoire secondaire non reconnues non reconnues ne restituent pas l’ensemble de l’entrée de répertoire définie comme non reconnue.

Les implémentations peuvent ignorer toute entrée secondaire bénigne qu’elle ne reconnaît pas.

6.4.1.3 Champ TypeCategory

Le champ TypeCategory doit être conforme à la définition fournie dans le modèle Generic DirectoryEntry (voir section 6.2.1.3).

Pour ce modèle, la valeur valide de ce champ est 1.

6.4.1.4 Champ InUse

Le champ InUse doit être conforme à la définition fournie dans le modèle Generic DirectoryEntry (voir section 6.2.1.4).

6.4.2 Champ GeneralSecondaryFlags

Le champ GeneralSecondaryFlags contient des indicateurs (voir Tableau 19).

Tableau 19 GénéralSecondaryFlags générique

nom de champ

offset

(bit)

taille

(bits)

 commentaires
AllocationPossible 0 1 Ce champ est obligatoire et section 6.4.2.1 définit son contenu.
NoFatChain 1 1 Ce champ est obligatoire et section 6.4.2.2 définit son contenu.
CustomDefined 2 6 Ce champ est obligatoire et les structures dérivées de ce modèle peuvent définir ce champ.
6.4.2.1 Champ AllocationPossible

Le champ AllocationPossible doit avoir la même définition que le champ nommé identique dans le modèle Primary DirectoryEntry générique (voir section 6.3.4.1).

6.4.2.2 Champ NoFatChain

Le champ NoFatChain doit avoir la même définition que le champ nommé dans le modèle Primary DirectoryEntry générique (voir section 6.3.4.2).

6.4.3 Champ FirstCluster

Le champ FirstCluster doit être conforme à la définition fournie dans le modèle Generic DirectoryEntry (voir section 6.2.2).

Si le bit NoFatChain est 1, FirstCluster doit pointer vers un cluster valide dans le tas de cluster.

6.4.4 Champ DataLength

Le champ DataLength doit être conforme à la définition fournie dans le modèle Generic DirectoryEntry (voir section 6.2.3).

Si le bit NoFatChain est 1, DataLength ne doit pas être égal à zéro. Si le champ FirstCluster est égal à zéro, DataLength doit également être égal à zéro.

7 Définitions d’entrée d’annuaire

La révision 1.00 du système de fichiers exFAT définit les entrées de répertoire suivantes :

7.1 Entrée de répertoire bitmap d’allocation

Dans le système de fichiers exFAT, un fat ne décrit pas l’état d’allocation des clusters ; plutôt qu’une bitmap d’allocation. Les bitmaps d’allocation existent dans le tas de cluster (voir section 7.1.5) et ont des entrées de répertoire primaire critiques correspondantes dans le répertoire racine (voir Tableau 20).

Le champ NumberOfFats détermine le nombre d’entrées de répertoires Bitmap d’allocation valides dans le répertoire racine. Si le champ NumberOfFats contient la valeur 1, le seul nombre valide d’entrées de répertoire Bitmap d’allocation est 1. En outre, l’entrée de répertoire Bitmap d’allocation est valide uniquement si elle décrit la première image bitmap d’allocation (voir section 7.1.2.1). Si le champ NumberOfFats contient la valeur 2, le seul nombre valide d’entrées de répertoire Bitmap d’allocation est 2. En outre, les deux entrées de répertoire Bitmap d’allocation ne sont valides que si l’une décrit la première bitmap d’allocation et l’autre décrit la deuxième bitmap d’allocation.

Table 20, structure Bitmap DirectoryEntry d’allocation

nom de champ

offset

(octets)

taille

(octets)

 commentaires
Type d'entrée 0 1 Ce champ est obligatoire et section 7.1.1 définit son contenu.
BitmapFlags 1 1 Ce champ est obligatoire et section 7.1.2 définit son contenu.
Réservé 2 18 Ce champ est obligatoire et son contenu est réservé.
FirstCluster 20 4 Ce champ est obligatoire et section 7.1.3 définit son contenu.
LongueurDonnees Vingt-quatre 8 Ce champ est obligatoire et section 7.1.4 définit son contenu.

Champ EntryType 7.1.1

Le champ EntryType doit être conforme à la définition fournie dans le modèle Primary DirectoryEntry générique (voir section 6.3.1).

7.1.1.1 Champ TypeCode

Le champ TypeCode doit être conforme à la définition fournie dans le modèle Primary DirectoryEntry générique (voir section 6.3.1.1).

Pour une entrée de répertoire Bitmap d’allocation, la valeur valide de ce champ est 1.

7.1.1.2 Champ TypeImportance

Le champ TypeImportance doit être conforme à la définition fournie dans le modèle Primary DirectoryEntry générique (voir section 6.3.1.2).

Pour une entrée de répertoire Bitmap d’allocation, la valeur valide de ce champ est 0.

7.1.1.3 Champ TypeCategory

Le champ TypeCategory doit être conforme à la définition fournie dans le modèle Primary DirectoryEntry générique (voir section 6.3.1.3).

7.1.1.4 Champ InUse

Le champ InUse doit être conforme à la définition fournie dans le modèle Primary DirectoryEntry générique (voir section 6.3.1.4).

7.1.2 Champ BitmapFlags

Le champ BitmapFlags contient des indicateurs (voir Tableau 21).

Tableau 21 BitmapFlags, structure de champ

nom de champ

offset

(bit)

taille

(bits)

 commentaires
BitmapIdentifier 0 1 Ce champ est obligatoire et section 7.1.2.1 définit son contenu.
Réservé 1 7 Ce champ est obligatoire et son contenu est réservé.
7.1.2.1 Champ BitmapIdentifier

Le champ BitmapIdentifier indique la bitmap d’allocation décrite par l’entrée de répertoire donnée. Les implémentations utilisent la première image bitmap d’allocation conjointement avec first FAT et utilisent la deuxième image bitmap d’allocation conjointement avec la deuxième fat. Le champ ActiveFat décrit quelles images FAT et Allocation Bitmap sont actives.

Les valeurs valides pour ce champ doivent être les suivantes :

  • 0, ce qui signifie que l’entrée de répertoire donnée décrit la première bitmap d’allocation
  • 1, ce qui signifie que l’entrée de répertoire donnée décrit la deuxième bitmap d’allocation et n’est possible que lorsque NumberOfFats contient la valeur 2

7.1.3 Champ FirstCluster

Le champ FirstCluster doit être conforme à la définition fournie dans le modèle Primary DirectoryEntry générique (voir section 6.3.5).

Ce champ contient l’index du premier cluster de la chaîne de cluster, comme le décrit fat, qui héberge la bitmap d’allocation.

7.1.4 Champ DataLength

Le champ DataCluster doit être conforme à la définition fournie dans le modèle Primary DirectoryEntry générique (voir section 6.3.6).

7.1.5 Bitmap d’allocation

Une bitmap d’allocation enregistre l’état d’allocation des clusters dans le tas de clusters. Chaque bit d’une bitmap d’allocation indique si son cluster correspondant est disponible pour l’allocation ou non.

Une bitmap d’allocation représente les clusters de l’index le plus bas au plus élevé (voir Tableau 22). Pour des raisons historiques, le premier cluster a l’index 2.

Remarque

Le premier bit de la bitmap est le bit de l’ordre le plus bas du premier octet.

table 22, structure bitmap d’allocation

nom de champ

offset

(bit)

taille

(bits)

 commentaires
BitmapEntry[2] 0 1 Ce champ est obligatoire et la section section 7.1.5.1 définit son contenu.

.

.

.

.

.

.

.

.

.

.

.

.
BitmapEntry[ClusterCount+1] ClusterCount - 1 1

Ce champ est obligatoire et section 7.1.5.1 définit son contenu.

Remarque : les secteurs de démarrage principal et de sauvegarde contiennent tous deux le champ ClusterCount.
Réservé Nombre de Clusters (DataLength * 8) – NombreDeClusters

Ce champ est obligatoire et son contenu, le cas échéant, sont réservés.

Remarque : les secteurs de démarrage principal et de sauvegarde contiennent tous deux le champ ClusterCount.
7.1.5.1 BitmapEntry[2] ... Champs BitmapEntry[ClusterCount+1]

Chaque champ BitmapEntry de ce tableau représente un cluster dans le tas de cluster. BitmapEntry[2] représente le premier cluster dans le tas de cluster et BitmapEntry[ClusterCount+1] représente le dernier cluster du tas de cluster.

Les valeurs valides pour ces champs doivent être les suivantes :

  • 0, qui décrit le cluster correspondant comme disponible pour l’allocation
  • 1, qui décrit le cluster correspondant comme non disponible pour l’allocation (une allocation de cluster peut déjà consommer le cluster correspondant ou le FAT actif peut décrire le cluster correspondant comme incorrect)

7.2 Entrée de répertoire de table à casse

La table à casse up définit la conversion de minuscules en caractères majuscules. Cela est important en raison de l’entrée du répertoire du nom de fichier (voir la section 7.7) à l’aide de caractères Unicode et du système de fichiers exFAT ne respectant pas la casse et la conservation de la casse. La table de cas up-case existe dans le tas de cluster (voir section 7.2.5) et a une entrée de répertoire primaire critique correspondante dans le répertoire racine (voir Tableau 23). Le nombre valide d’entrées du répertoire Table à cas élevé est 1.

En raison de la relation entre la table à casse up-case et les noms de fichiers, les implémentations ne doivent pas modifier la table de casse up, sauf en raison d’opérations de format.

Table 23 Structure d’entrée de répertoire de la table en majuscules

nom de champ

offset

(octets)

taille

(octets)

 commentaires
Type d'entrée 0 1 Ce champ est obligatoire et section 7.2.1 définit son contenu.
Réservé1 1 3 Ce champ est obligatoire et son contenu est réservé.
TableChecksum 4 4 Ce champ est obligatoire et section 7.2.2 définit son contenu.
Réservé2 8 12 Ce champ est obligatoire et son contenu est réservé.
FirstCluster 20 4 Ce champ est obligatoire et section 7.2.3 définit son contenu.
LongueurDonnees Vingt-quatre 8 Ce champ est obligatoire et section 7.2.4 définit son contenu.

7.2.1 Champ EntryType

Le champ EntryType doit être conforme à la définition fournie dans le modèle Primary DirectoryEntry générique (voir section 6.3.1).

7.2.1.1 Champ TypeCode

Le champ TypeCode doit être conforme à la définition fournie dans le modèle Primary DirectoryEntry générique (voir section 6.3.1.1).

Pour l’entrée de répertoire Table à cas haut, la valeur valide de ce champ est 2.

7.2.1.2 Champ TypeImportance

Le champ TypeImportance doit être conforme à la définition fournie dans le modèle Primary DirectoryEntry générique (voir section 6.3.1.2).

Pour l’entrée de répertoire Table à cas up-case, la valeur valide de ce champ est 0.

7.2.1.3 Champ TypeCategory

Le champ TypeCategory doit être conforme à la définition fournie dans le modèle Primary DirectoryEntry générique (voir section 6.3.1.3).

7.2.1.4 Champ InUse

Le champ InUse doit être conforme à la définition fournie dans le modèle Primary DirectoryEntry générique (voir section 6.3.1.4).

7.2.2 Champ TableChecksum

Le champ TableChecksum contient la somme de contrôle de la table up-case (que les champs FirstCluster et DataLength décrivent). Les implémentations vérifient que le contenu de ce champ est valide avant d’utiliser la table de cas d’utilisation.

Figure 3 Calcul tableChecksum

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 Champ FirstCluster

Le champ FirstCluster doit être conforme à la définition fournie dans le modèle Primary DirectoryEntry générique (voir section 6.3.5).

Ce champ contient l’index du premier cluster de la chaîne de cluster, comme le décrit fat, qui héberge la table à cas haut.

7.2.4 Champ DataLength

Le champ DataCluster doit être conforme à la définition fournie dans le modèle Primary DirectoryEntry générique (voir section 6.3.6).

7.2.5 Table de cas up-case

Une table à casse up est une série de mappages de caractères Unicode. Un mappage de caractères se compose d’un champ de 2 octets, avec l’index du champ dans la table de casse up représentant le caractère Unicode à caser, et le champ de 2 octets représentant le caractère Unicode up-cased.

Les 128 premiers caractères Unicode ont des mappages obligatoires (voir Tableau 24). Une table à casse up qui a tout autre mappage de caractères pour l’un des 128 premiers caractères Unicode n’est pas valide.

Les implémentations qui prennent uniquement en charge les caractères de la plage de mappage obligatoire peuvent ignorer les mappages du reste de la table de casse. Ces implémentations n’utilisent que des caractères de la plage de mappage obligatoire lors de la création ou du renommage de fichiers (via l’entrée de répertoire nom de fichier, consultez section 7.7). Lors de la casse des noms de fichiers existants, ces implémentations ne doivent pas mettre à jour les caractères de la plage de mappage non obligatoire, mais les laisser intacts dans le nom de fichier mis en casse résultant (il s’agit d’une casse partielle). Lors de la comparaison des noms de fichiers, ces implémentations traitent les noms de fichiers qui diffèrent du nom sous comparaison uniquement par les caractères Unicode de la plage de mappage non obligatoire comme équivalent. Bien que ces noms de fichiers ne soient potentiellement équivalents que, ces implémentations ne peuvent pas s’assurer que le nom de fichier entièrement casé ne se heurte pas au nom sous comparaison.

Tableau 24 Entrées obligatoires de 128 premières tables à casse

Index de table + 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

(Remarque : les entrées avec des mappages sans casse d’identité sont en gras)

Lors de la mise en forme d’un volume, les implémentations peuvent générer une table de casse up-case dans un format compressé à l’aide de la compression de mappage d’identité, car une grande partie de l’espace de caractères Unicode n’a pas de concept de cas (ce qui signifie que les caractères « minuscules » et « majuscules » sont équivalents). Les implémentations compressent une table de cas up-case en représentant une série de mappages d’identités avec la valeur FFFFh suivie du nombre de mappages d’identité.

Par exemple, une implémentation peut représenter les 100 premiers mappages de caractères (64h) avec les huit entrées suivantes d’une table de casse compressée :

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

Les deux premières entrées indiquent les 97 premiers caractères (61h) (de 0000h à 0060h) ont des mappages d’identité. Les caractères suivants, 0061h à 0063h, correspondent respectivement aux caractères 0041h à 0043h.

La possibilité de fournir une table à casse compressée lors de la mise en forme d’un volume est facultative. Toutefois, la possibilité d’interpréter à la fois une table non compressée et une table à casse compressée est obligatoire. La valeur du champ TableChecksum est toujours conforme à la façon dont la table de casse up existe sur le volume, qui peut être au format compressé ou non compressé.

Lors de la mise en forme d’un volume, les implémentations doivent enregistrer la table de casse recommandée au format compressé (voir Tableau 25), pour laquelle la valeur du champ TableChecksum est E619D30Dh.

Si une implémentation définit sa propre table de casse, compressée ou non compressée, cette table doit couvrir la plage de caractères Unicode complète (entre les codes de caractères 0000h et FFFFh inclus).