Spécification du système de fichiers exFAT

  • Article

1 Introduction

Le système de fichiers exFAT est le successeur de FAT32 dans la famille de systèmes de fichiers FAT. 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. Conservez la simplicité des systèmes de fichiers 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 doivent trouver exFAT relativement simple et facile à mettre en œuvre.

  2. Activez 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 des fichiers, ce qui permet aux applications qui dépendent de fichiers très volumineux. Le système de fichiers exFAT permet également d’utiliser des clusters d’une taille de 32 Mo, ce qui permet de très grands périphériques de stockage.

  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 le rythme des innovations en matière de stockage et des changements d’utilisation.

1.2 Terminologie spécifique

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

Tableau 1 Définition des termes qui ont une signification très spécifique

Terme Définition
Est Cette spécification utilise le terme « shall » pour décrire un comportement obligatoire.
Recommandé Cette spécification utilise le terme « should » pour décrire un comportement qu’elle recommande vivement, mais ne rend pas obligatoire.
Mai Cette spécification utilise le terme « peut » pour décrire un comportement facultatif.
Obligatoire Ce terme décrit un champ ou une structure qu’une implémentation doit modifier et doit interpréter comme décrit cette spécification.
Facultatif 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 dans cette spécification.
Indéfini Ce terme décrit le contenu d’un champ ou d’une structure qu’une implémentation peut modifier si nécessaire (c’est-à-dire effacer à zéro lors de la définition des champs ou structures environnants) et ne doit pas interpréter pour avoir une signification spécifique.
Réservé

Ce terme décrit le contenu d’un champ ou d’une structure qui met en œuvre :

  1. Doit être initialisé à zéro et ne doit pas utiliser à quelque fin que ce soit

  2. Ne doit pas interpréter, sauf lors du calcul des sommes de contrôle

  3. Doit conserver entre les opérations qui modifient les champs ou structures environnants

1.3 Texte intégral des acronymes courants

Cette spécification utilise des acronymes couramment utilisés dans l’industrie des ordinateurs personnels (voir le tableau 2).

Tableau 2 Texte intégral des acronymes courants

Acronyme Texte complet
ASCII American Standard Code for Information Interchange
BIOS Système de sortie d’entrée de base
UC Unité centrale de traitement
exFAT table d’allocation de fichiers extensible
FAT 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 la section 10.1)
INT Interruption
partition Enregistrement de démarrage principal
texFAT ExFAT sécurisé pour les transactions
UTC Temps universel coordonné

1.4 Qualificateurs de structure et de champ par défaut

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

  1. Sont non signés

  2. Utilisez la notation décimale pour décrire les valeurs, là où elles ne sont pas indiquées ; cette spécification utilise la lettre post-correction « h » pour désigner les nombres hexadécimaux et entoure les GUID dans des accolades

  3. Sont au format little-endian

  4. Ne pas exiger de caractère de fin Null pour les chaînes

1,5 Windows CE et TexFAT

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

Structure de 2 volumes

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

Structure des volumes du tableau 3

Nom de la 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 la section 3.1 définit son contenu.
Principaux secteurs de démarrage étendus 1 8 Cette sous-région est obligatoire et la section 3.2) définit son contenu.
Principaux paramètres OEM 9 1 Cette sous-région est obligatoire et la section 3.3 définit son contenu.
Réservé principal 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 la 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 la section 3.1 définit son contenu.
Secteurs de démarrage étendus de sauvegarde 13 8 Cette sous-région est obligatoire et la section 3.2 définit son contenu.
Paramètres OEM de sauvegarde 21 1 Cette sous-région est obligatoire et la 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 la section 3.4 définit son contenu.
Région FAT
Alignement FAT 24 FatOffset – 24

Cette sous-région est obligatoire et son contenu, le cas échéant, n’est pas défini.

Remarque : les secteurs de démarrage principal et de sauvegarde contiennent tous deux le champ FatOffset.
Premier FAT FatOffset FatLength

Cette sous-région est obligatoire et la 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 la 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, n’est pas défini.

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 * 2SecteursPerClusterShift

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

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

Cette sous-région est obligatoire et son contenu, le cas échéant, n’est pas défini.

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

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

La région De démarrage principal fournit toutes les instructions de démarrage nécessaires, les informations d’identification 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 d’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 principal. Il permet de récupérer le volume exFAT dans le cas où la région Main Boot se trouve dans un état incohérent. Sauf dans des circonstances peu fréquentes, telles que la mise à jour des instructions d’amorçage, les implémentations ne doivent pas modifier le contenu de la région de démarrage de sauvegarde.

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

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

Le secteur de démarrage de la 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 faciliter les opérations de récupération ; toutefois, les implémentations doivent traiter le contenu des champs VolumeFlags et PercentInUse comme obsolète.

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

Bien que l’opération de mise en forme initiale initialise le contenu des secteurs de démarrage principal et de sauvegarde, les implémentations peuvent mettre à jour ces secteurs (et doivent également mettre à 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).

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

Nom du champ

Offset

(octet)

Taille

(octets)

 Commentaires
JumpBoot 0 3 Ce champ est obligatoire et la section 3.1.1 définit son contenu.
FileSystemName 3 8 Ce champ est obligatoire et la section 3.1.2 définit son contenu.
MustBeZero 11 53 Ce champ est obligatoire et la section 3.1.3 définit son contenu.
PartitionOffset 64 8 Ce champ est obligatoire et la section 3.1.4 définit son contenu.
VolumeLength 72 8 Ce champ est obligatoire et la section 3.1.5 définit son contenu.
FatOffset 80 4 Ce champ est obligatoire et la section 3.1.6 définit son contenu.
FatLength 84 4 Ce champ est obligatoire et la section 3.1.7 définit son contenu.
ClusterHeapOffset 88 4 Ce champ est obligatoire et la section 3.1.8 définit son contenu.
ClusterCount 92 4 Ce champ est obligatoire et la section 3.1.9 définit son contenu.
FirstClusterOfRootDirectory 96 4 Ce champ est obligatoire et la section 3.1.10 définit son contenu.
VolumeSerialNumber 100 4 Ce champ est obligatoire et la section 3.1.11 définit son contenu.
FileSystemRevision 104 2 Ce champ est obligatoire et la section 3.1.12 définit son contenu.
VolumeFlags 106 2 Ce champ est obligatoire et la section 3.1.13 définit son contenu.
BytesPerSectorShift 108 1 Ce champ est obligatoire et la section 3.1.14 définit son contenu.
SectorsPerClusterShift 109 1 Ce champ est obligatoire et la section 3.1.15 définit son contenu.
NumberOfFats 110 1 Ce champ est obligatoire et la section 3.1.16 définit son contenu.
DriveSelect 111 1 Ce champ est obligatoire et la section 3.1.17 définit son contenu.
PercentInUse 112 1 Ce champ est obligatoire et la 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 la section 3.1.19 définit son contenu.
BootSignature 510 2 Ce champ est obligatoire et la section 3.1.20 définit son contenu.
ExcessSpace 512 2BytesPerSectorShift – 512

Ce champ est obligatoire et son contenu, le cas échéant, n’est pas défini.

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

3.1.1 Champ JumpBoot

Le champ JumpBoot doit contenir l’instruction de saut pour les processeurs courants dans les ordinateurs personnels, qui, lorsqu’il est exécuté, « saute » le processeur pour exécuter les instructions de démarrage dans le champ BootCode.

La valeur valide pour ce champ est (dans l’ordre d’octet de bas ordre à octet d’ordre élevé) 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 pour ce champ est, en caractères ASCII, « EXFAT », qui comprend trois espaces blancs de fin.

3.1.3 Champ MustBezero

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

La valeur valide pour 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 doit décrire le décalage de secteur relatif du média de la partition qui héberge le volume exFAT donné. Ce champ facilite le démarrage à partir du volume à l’aide de l’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 VolumeLength Field

Le champ VolumeLength doit décrire 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 maximum 264- 1, la valeur la plus élevée 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) * 2SecteursPerClusterShift.

3.1.6 Champ FatOffset

Le champ FatOffset décrit le décalage de 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, ce qui tient compte des secteurs que les régions de démarrage principal et de démarrage de sauvegarde consomment

  • Au plus ClusterHeapOffset - (FatLength * NumberOfFats), qui tient compte des secteurs que le tas de cluster consomme

3.1.7 Champ FatLength

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

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

  • Au moins (ClusterCount + 2) * 22/ 2OctetsPerSectorShiftarrondi à 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 plus (ClusterHeapOffset - FatOffset) / NumberOfFats arrondi à l’entier le plus proche, ce qui garantit que les FAT 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 également aligné sur les caractéristiques du support de stockage sous-jacent. Le contenu de l’espace qui dépasse ce que le FAT lui-même nécessite, le cas échéant, n’est pas défini.

3.1.8 Champ ClusterHeapOffset

Le champ ClusterHeapOffset doit décrire le décalage de 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 prendre en compte les secteurs que toutes les régions précédentes consomment

  • Au maximum 232- 1 ou VolumeLength - (ClusterCount * 2SectorsPerClusterShift), selon le calcul qui est inférieur

3.1.9 Champ ClusterCount

Le champ ClusterCount doit décrire le nombre de clusters que contient le tas de cluster.

La valeur valide pour ce champ doit être la plus petite des valeurs suivantes :

  • (VolumeLength - ClusterHeapOffset) / 2SectorsPerClusterShiftarrondi au nombre entier le plus proche, qui correspond exactement au nombre de clusters qui peuvent s’adapter entre le début du tas de cluster et la fin du volume

  • 232- 11, qui est 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 les fats extrêmement volumineux, les implémentations peuvent contrôler le nombre de clusters dans le tas de cluster en augmentant la taille du cluster (via le champ SectorsPerClusterShift). Cette spécification recommande de ne pas dépasser 2clusters 24 à 2 dans le tas de cluster. Toutefois, les implémentations doivent être en mesure de gérer des volumes avec jusqu’à 2clusters 32-11 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 déployer tous les efforts nécessaires pour placer le premier cluster du répertoire racine dans le premier cluster non défectueux après l’utilisation des clusters Bitmap d’allocation et Up-case Table.

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

  • Au moins 2, index du premier cluster dans le tas de cluster

  • Au maximum ClusterCount + 1, l’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 à faire la distinction entre 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 mise en forme du volume exFAT. Le mécanisme permettant de combiner la date et l’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 doit décrire les numéros de révision majeurs et mineurs des structures exFAT sur le volume donné.

L’octet d’ordre élevé est le numéro de révision principal et l’octet de bas ordre est le numéro de révision mineur. Par exemple, si l’octet d’ordre élevé contient la valeur 01h et si l’octet de bas ordre contient la valeur 05h, le champ FileSystemRevision décrit le numéro de révision 1.05. De même, si l’octet d’ordre élevé contient la valeur 0Ah et si l’octet de bas 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 d’ordre élevé

  • Au maximum 99 pour l’octet de faible ordre et 99 pour l’octet d’ordre élevé

Le numéro de révision d’exFAT décrit par cette spécification est 1.00. Les implémentations de cette spécification doivent monter tout volume exFAT avec le numéro de révision majeur 1 et ne doivent pas monter un volume exFAT avec un autre numéro de révision majeur. Les implémentations doivent respecter le numéro de révision mineur et ne doivent pas effectuer d’opérations ni créer des structures de système de fichiers non décrites dans la spécification correspondante du numéro de révision mineur donné.

3.1.13 Champ VolumeFlags

Le champ VolumeFlags doit contenir des indicateurs qui indiquent l’status de différentes structures de système de fichiers sur le volume exFAT (voir le tableau 5).

Les implémentations n’incluent pas ce champ lors du calcul de sa somme de contrôle de démarrage principal 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 doivent traiter ce champ comme obsolète.

Tableau 5 Structure de champ VolumeFlags

Nom du champ

Offset

(bit)

Taille

(bits)

 Commentaires
ActiveFat 0 1 Ce champ est obligatoire et la section 3.1.13.1 définit son contenu.
VolumeDirty 1 1 Ce champ est obligatoire et la section 3.1.13.2 définit son contenu.
MediaFailure 2 1 Ce champ est obligatoire et la section 3.1.13.3 définit son contenu.
ClearToZero 3 1 Ce champ est obligatoire et la 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 doit décrire les bitmaps d’allocation et DE FAT qui sont actifs (et les implémentations doivent utiliser), comme suit :

  • 0, ce qui signifie que la première fat et la première bitmap d’allocation sont actives

  • 1, ce qui signifie que le second FAT et le second bitmap d’allocation sont actifs et n’est possible que lorsque le champ NumberOfFats contient la valeur 2

Les implémentations doivent considérer les fichiers FAT et Bitmap d’allocation inactifs comme obsolètes. Seules les implémentations compatibles avec TexFAT doivent changer les bitmaps FAT et Allocation actives (voir section 7.1).

3.1.13.2 Champ VolumeDirty

Le champ VolumeDirty doit indiquer 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 lorsqu’elles rencontrent des 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 sur 0. Ces implémentations ne doivent effacer la valeur de ce champ sur 0 qu’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 l’ordre d’écriture recommandé décrit à la section 8.1.

3.1.13.3 Champ MediaFailure

Le champ MediaFailure doit indiquer si une implémentation a découvert ou non des défaillances multimédias, comme suit :

  • 0, ce qui signifie que le média d’hébergement n’a pas signalé d’échecs ou que les défaillances connues sont déjà enregistrées dans le FAT en tant que clusters « défectueux »

  • 1, ce qui signifie que le média 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 dans les cas suivants :

  1. Le média d’hébergement échoue à des tentatives d’accès à n’importe quelle région dans le 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 à la recherche de défaillances de média et enregistrent toutes les défaillances en tant que clusters « incorrects » dans la fat (ou résolvent les défaillances de média) peuvent effacer la valeur de ce champ sur 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 pas de 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 doit décrire les octets par secteur exprimés sous la forme log2(N), où N est le 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 de secteur de 512 octets), qui est le plus petit secteur possible pour un volume exFAT

  • Au maximum 12 (taille de secteur de 4 096 octets), qui correspond à la taille de page mémoire des processeurs courants sur les ordinateurs personnels

3.1.15 SecteursPerClusterShift Field

Le champ SectorsPerClusterShift doit décrire les secteurs par cluster exprimés sous la forme log2(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 est évalué à une taille de cluster de 32 Mo

3.1.16 Champ NumberOfFats

Le champ NumberOfFats doit décrire le nombre de fichiers DEF et de bitmaps d’allocation que contient le volume.

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

  • 1, qui indique que le volume contient uniquement les bitmaps First FAT et First Allocation

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

3.1.17 DriveSelect Field

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

Toutes les valeurs possibles pour ce champ sont valides. Des champs similaires dans les systèmes de fichiers FAT précédents contenaient souvent la valeur 80h.

3.1.18 CentInUtiliser le champ

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

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

  • Compris entre 0 et 100 inclusivement, qui correspond au 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 cluster n’est pas disponible

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

Les implémentations ne doivent pas inclure ce champ lors du calcul de leur somme de contrôle de la région de démarrage principal ou de démarrage de sauvegarde respective. Lorsqu’elles font référence au secteur de démarrage de la sauvegarde, les implémentations doivent traiter ce champ comme obsolète.

3.1.19 Champ BootCode

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

3.1.20 Champ BootSignature

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

La valeur valide pour 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 de tout autre champ dans son secteur de démarrage respectif.

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

Chaque secteur des principaux secteurs de démarrage étendus a la même structure ; toutefois, chaque secteur peut contenir des instructions distinctes pour le cerclage de démarrage (voir le tableau 6). Les agents de cerclage de démarrage, tels que les instructions de cerclage 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 étendus de sauvegarde sont une sauvegarde des principaux secteurs de démarrage étendus et ont la même structure (voir le 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 mise en forme initiale initialise le contenu des secteurs de démarrage principal et de sauvegarde, les implémentations peuvent mettre à jour ces secteurs (et mettre également à jour leur somme de contrôle de démarrage respective) si nécessaire.

Tableau 6 Structure étendue du secteur de démarrage

Nom du champ

Offset

(octet)

Taille

(octets)

 Commentaires
ExtendedBootCode 0 2BytesPerSectorShift – 4

Ce champ est obligatoire et la 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 2BytesPerSectorShift – 4 4

Ce champ est obligatoire et la 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 démarrage. Les implémentations peuvent remplir ce champ avec les instructions du processeur nécessaires au démarrage d’un système informatique. Les implémentations qui ne fournissent pas d’instructions d’amorçage doivent initialiser chaque octet de ce champ à 00h dans le cadre de leur opération de mise en forme.

3.2.2 Champ ExtendedBootSignature

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

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

3.3 Sous-régions Paramètres OEM principaux et de sauvegarde

La sous-région Paramètres OEM principaux contient dix structures de paramètres qui peuvent contenir des informations spécifiques au fabricant (voir le 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 elle-même définit deux structures de paramètres : Les paramètres Null (voir la section 3.3.3) et les paramètres Flash (voir la 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 le tableau 7).

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

Les fabricants doivent remplir les paramètres OEM principal et de sauvegarde 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 principal 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 du champ

Offset

(octet)

Taille

(octets)

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

.

.

.

.

.

.

.

.

.

.

.

.
Paramètres[9] 432 48 Ce champ est obligatoire et la 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é doit être décrit comme contenant une structure 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 le 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 du tableau 8

Nom du champ

Offset

(octet)

Taille

(octets)

 Commentaires
ParametersGuid 0 16 Ce champ est obligatoire et la section 3.3.2.1 définit son contenu.
CustomDefined 16 32 Ce champ est obligatoire et les structures qui dérivent de ce modèle définissent son contenu.
3.3.2.1 ParametersGuid Field

Le champ ParametersGuid doit décrire 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 de 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 doit décrire un champ Paramètres inutilisé (voir le tableau 9). Lors de la création ou de la mise à jour de la structure paramètres OEM, les implémentations doivent remplir 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 paramètres OEM, les implémentations doivent consolider les structures paramètres Null à la fin du tableau, laissant ainsi toutes les autres structures Parameters au début de la structure paramètres OEM.

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

Structure des paramètres Null du tableau 9

Nom du champ

Offset

(octet)

Taille

(octets)

 Commentaires
ParametersGuid 0 16 Ce champ est obligatoire et la 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 ParametersGuid Field

Le champ ParametersGuid doit être conforme à la définition fournie par le modèle Paramètres génériques (voir la 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 De paramètre Flash dérive du modèle Paramètres génériques (voir section 3.3.2) et contient des paramètres pour les médias flash (voir le tableau 10). Les fabricants de périphériques de stockage flash peuvent remplir un champ Paramètres (de préférence le champ Paramètres[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 qui utilisent la mise en forme du média.

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

Structure des paramètres Flash du tableau 10

Nom du champ

Offset

(octet)

Taille

(octets)

 Commentaires
ParametersGuid 0 16 Ce champ est obligatoire et la section 3.3.4.1 définit son contenu.
EraseBlockSize 16 4 Ce champ est obligatoire et la section 3.3.4.2 définit son contenu.
PageSize 20 4 Ce champ est obligatoire et la section 3.3.4.3 définit son contenu.
SpareSectors 24 4 Ce champ est obligatoire et la section 3.3.4.4 définit son contenu.
RandomAccessTime 28 4 Ce champ est obligatoire et la section 3.3.4.5 définit son contenu.
ProgrammingTime 32 4 Ce champ est obligatoire et la section 3.3.4.6 définit son contenu.
ReadCycle 36 4 Ce champ est obligatoire et la section 3.3.4.7 définit son contenu.
WriteCycle 40 4 Ce champ est obligatoire et la 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 est réellement vide de sens (les implémentations doivent ignorer le champ donné).

3.3.4.1 Parameters FieldGuid

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 PageSize Field

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 dont dispose le média flash pour ses opérations d’épargne interne.

3.3.4.5 Champ RandomAccessTime

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

3.3.4.6 Champ ProgrammingTime

Le champ ProgrammingTime décrit la durée de programmation moyenne 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 support flash, en nanosecondes.

3.3.4.8 Champ WriteCycle

Le champ WriteCycle décrit la durée moyenne du cycle d’écriture, en nanosecondes.

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

Les sommes de contrôle de démarrage principal et de sauvegarde contiennent chacune un modèle répétiteur 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 la somme de contrôle ne doit pas inclure les champs VolumeFlags et PercentInUse dans leur secteur de démarrage respectif (voir figure 1). Le modèle de répétition de la somme de contrôle de quatre octets remplit sa sous-région De vérification 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 doivent vérifier leur contenu en validant leur somme de contrôle de démarrage respective.

Bien que l’opération de mise en forme initiale remplit les sommes de contrôle de démarrage principal et de sauvegarde avec le modèle de somme de contrôle répétée, les implémentations doivent mettre à jour ces secteurs à mesure que le contenu des autres secteurs de leurs régions de démarrage respectives change.

Figure 1 Calcul de la 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 table d’allocation de fichiers

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

Le champ ActiveFat du champ VolumeFlags décrit quel FAT est actif. Seul le champ VolumeFlags dans le secteur de démarrage principal est à jour. Les implémentations doivent traiter le FAT qui n’est pas actif comme obsolète. L’utilisation du FAT inactif et le basculement entre les FTE sont spécifiques à 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 le tableau 11). Une chaîne de cluster est une série de clusters qui fournit 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 séparément. À l’exception des deux premières entrées, chaque entrée d’un FAT représente exactement un cluster.

Tableau 11 Structure de table d’allocation de fichiers

Nom du champ

Offset

(octet)

Taille

(octets)

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

.

.

.

.

.

.

.

.

.

.

.

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

Ce champ est obligatoire et la 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, n’est pas défini.

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

4.1.1 Champ FatEntry[0]

Le champ FatEntry[0] doit décrire le type de média dans le premier octet (l’octet d’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 Champ FatEntry[1]

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

La valeur valide pour ce champ est FFFFFFFFh. Les implémentations initialisent ce champ à sa valeur prescrite et ne doivent pas utiliser ce champ à quelque fin que ce soit. Les implémentations ne doivent pas interpréter ce champ et doivent conserver son contenu dans 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, inclusivement, qui pointe vers le fatEntry suivant dans la chaîne de cluster donnée ; le FatEntry donné ne pointe vers aucun FatEntry qui le précède dans la chaîne de cluster donnée

  • Exactement FFFFFFFFF7h, ce qui marque le cluster correspondant de FatEntry donné comme « mauvais »

  • Exactement FFFFFFFFh, qui marque le cluster correspondant de FatEntry donné comme le dernier cluster d’une chaîne de cluster ; il s’agit de la seule valeur valide pour la dernière FatEntry d’une chaîne de cluster donnée

5 Région de données

La région Données contient le tas de cluster, qui fournit de l’espace managé pour les structures de système de fichiers, les répertoires et les 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 2, 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 lesquels un FAT a conservé un enregistrement de l’état d’allocation de tous les clusters dans le tas de cluster.

Tableau 12 Structure du tas de cluster

Nom du champ

Offset

(secteur)

Taille

(secteurs)

 Commentaires
Cluster[2] ClusterHeapOffset 2SecteursPerClusterShift

Ce champ est obligatoire et la 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) * 2SecteursPerClusterShift 2SecteursPerClusterShift

Ce champ est obligatoire et la 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 de système de fichiers et les fichiers qui existent dans le tas de cluster. Les répertoires ont une relation un-à-plusieurs entre le parent et l’enfant dans l’arborescence de répertoires.

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 liée séparément.

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

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

Structure de répertoires du tableau 13

Nom du champ

Offset

(octet)

Taille

(octet)

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

.

.

.

.

.

.

.

.

.

.

.

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

Ce champ est obligatoire et la 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ée 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 DirectoryEntry générique (voir section 6.2).

6.2 Modèle DirectoryEntry générique

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

Tableau 14 Modèle DirectoryEntry générique

Nom du champ

Offset

(octet)

Taille

(octet)

 Commentaires
EntryType 0 1 Ce champ est obligatoire et la section 6.2.1 définit son contenu.
CustomDefined 1 19 Ce champ est obligatoire et les structures qui dérivent de ce modèle peuvent définir son contenu.
FirstCluster 20 4 Ce champ est obligatoire et la section 6.2.2 définit son contenu.
DataLength 24 8 Ce champ est obligatoire et la section 6.2.3 définit son contenu.

6.2.1 Champ EntryType

Le champ EntryType a trois modes d’utilisation définis par la valeur du champ (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’objet DirectoryEntry 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 de répertoire

    • Les implémentations peuvent remplacer les marqueurs de fin de répertoire si nécessaire

  • Entre 01h et 7Fh inclusivement, ce qui est un marqueur d’entrée d’annuaire inutilisé et les conditions suivantes s’appliquent :

    • Tous les autres champs de l’objet DirectoryEntry donné ne sont en fait pas définis

    • Les entrées de répertoire inutilisées ne sont valides qu’en dehors des jeux d’entrées de répertoire

    • Les implémentations peuvent remplacer les entrées de répertoire 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 inclusivement, qui est une entrée de répertoire normale 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 toute modification du champ InUse (voir section 6.2.1.4) entraînant par erreur un marqueur de fin de répertoire, la valeur 80h n’est pas valide.

Tableau 15 Structure de champ EntryType générique

Nom du champ

Offset

(bit)

Taille

(bits)

 Commentaires
TypeCode 0 5 Ce champ est obligatoire et la section 6.2.1.1 définit son contenu.
TypeImportance 5 1 Ce champ est obligatoire et la section 6.2.1.2 définit son contenu.
TypeCategory 6 1 Ce champ est obligatoire et la section 6.2.1.3 définit son contenu.
InUse 7 1 Ce champ est obligatoire et la section 6.2.1.4 définit son contenu.
6.2.1.1 TypeCode Field

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 tous deux la valeur 0 ; dans ce cas, la valeur 0 n’est pas valide pour ce champ.

6.2.1.2 TypeImportance Field

Le champ TypeImportance doit décrire 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 principal et secondaire critique, respectivement)

  • 1, ce qui signifie que l’entrée de répertoire donnée est bénigne (voir section 6.3.1.2.2 et section 6.4.1.2.2 pour les entrées d’annuaire primaire et secondaire bénignes, respectivement)

6.2.1.3 TypeCategory Field

Le champ TypeCategory doit décrire 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 InUtilisation

Le champ InUse doit indiquer si l’entrée de répertoire donnée est utilisée 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 en cours d’utilisation ; cela signifie que la structure donnée est en fait une entrée de répertoire 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’il n’existe aucune allocation de cluster

  • 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 maximum 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’entrée de répertoire principal générique

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

La possibilité d’interpréter le modèle Generic Primary DirectoryEntry est obligatoire.

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

Tableau 16 - Modèle d’entrée de répertoire principal générique

Nom du champ

Offset

(octet)

Taille

(octet)

 Commentaires
EntryType 0 1 Ce champ est obligatoire et la section 6.3.1 définit son contenu.
SecondaryCount 1 1 Ce champ est obligatoire et la section 6.3.2 définit son contenu.
SetChecksum 2 2 Ce champ est obligatoire et la section 6.3.3 définit son contenu.
GeneralPrimaryFlags 4 2 Ce champ est obligatoire et la section 6.3.4 définit son contenu.
CustomDefined 6 14 Ce champ est obligatoire et les structures qui dérivent de ce modèle définissent son contenu.
FirstCluster 20 4 Ce champ est obligatoire et la section 6.3.5 définit son contenu.
DataLength 24 8 Ce champ est obligatoire et la 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 la section 6.2.1).

6.3.1.1 TypeCode Field

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 TypeImportance Field

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 bonne gestion d’un volume exFAT. Seul le répertoire racine contient des entrées de répertoire principal critiques (les entrées de répertoire de fichiers sont une exception, voir 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 principal critiques que cette spécification définit.

6.3.1.2.2 Entrées bénignes du répertoire principal

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 principal bénignes.

La définition des 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 toute entrée de répertoire principal bénigne définie par cette spécification, ou toute spécification ultérieure, est facultative. Une entrée de répertoire principal sans gravité non reconnue rend 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 TypeCategory Field

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 pour ce champ doit être 0.

6.3.1.4 Champ InUtilisation

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 doit décrire le nombre d’entrées de répertoire secondaire qui suivent immédiatement l’entrée de répertoire principal donnée. Ces entrées de répertoire secondaire, ainsi que l’entrée de répertoire principal donnée, constituent l’ensemble d’entrées de répertoire.

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

  • Au moins 0, ce qui signifie que cette entrée de répertoire principal est la seule entrée dans le jeu d’entrées de répertoire

  • Au maximum 255, ce qui signifie que les 255 entrées de répertoire suivantes et cette entrée de répertoire principal comprennent l’ensemble d’entrées de répertoire

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 de répertoire dans le jeu d’entrées de répertoire donné. Toutefois, la somme de contrôle exclut ce champ (voir figure 2). Les implémentations doivent vérifier 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 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 GeneralPrimaryFlags Field

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éral génériquePrimaryFlags Field Structure

Nom du champ

Offset

(bit)

Taille

(bits)

 Commentaires
AllocationPossible 0 1 Ce champ est obligatoire et la section 6.3.4.1 définit son contenu.
NoFatChain 1 1 Ce champ est obligatoire et la section 6.3.4.2 définit son contenu.
CustomDefined 2 14 Ce champ est obligatoire et les structures qui dérivent de ce modèle peuvent définir ce champ.
6.3.4.1 Allocation FieldPossible

Le champ AllocationPossible doit décrire 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 en fait pas définis (les structures qui dérivent 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 tels que définis

6.3.4.2 Champ NoFatChain

Le champ NoFatChain doit indiquer 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 que 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 doivent pas les interpréter ; 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 de toute 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 la 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 qui dérivent 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 qui dérivent 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ériqueEntry

L’objectif central des entrées d’annuaire secondaires est de fournir des informations supplémentaires sur un jeu d’entrées d’annuaire. La possibilité d’interpréter le modèle Répertoire secondaire générique Est obligatoire.

La définition des entrées de répertoire secondaire critiques et bénignes 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énigne définie par 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 Generic Secondary DirectoryEntry (voir le tableau 18), qui dérive du modèle Generic DirectoryEntry (voir la section 6.2).

Tableau 18 Modèle d’annuaire secondaire génériqueEntry

Nom du champ

Offset

(octet)

Taille

(octet)

 Commentaires
EntryType 0 1 Ce champ est obligatoire et la section 6.4.1 définit son contenu.
GeneralSecondaryFlags 1 1 Ce champ est obligatoire et la section 6.4.2 définit son contenu.
CustomDefined 2 18 Ce champ est obligatoire et les structures qui dérivent de ce modèle définissent son contenu.
FirstCluster 20 4 Ce champ est obligatoire et la section 6.4.3 définit son contenu.
DataLength 24 8 Ce champ est obligatoire et la 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 DirectoryEntry générique (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 bonne gestion de son jeu d’entrées d’annuaire contenant. Bien que la prise en charge de toute entrée de répertoire secondaire critique spécifique soit facultative, une entrée de répertoire critique 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).

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 doit au plus interpréter les modèles des entrées d’annuaire dans le jeu d’entrées de répertoire et non les données qu’aucune allocation associée à 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 d’annuaire secondaires 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 ne rendent 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 pour ce champ est 1.

6.4.1.4 Champ InUtilisation

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 le tableau 19).

Tableau 19 Structure de champ Général SecondaireFlags générique

Nom du champ

Offset

(bit)

Taille

(bits)

 Commentaires
AllocationPossible 0 1 Ce champ est obligatoire et la section 6.4.2.1 définit son contenu.
NoFatChain 1 1 Ce champ est obligatoire et la section 6.4.2.2 définit son contenu.
CustomDefined 2 6 Ce champ est obligatoire et les structures qui dérivent de ce modèle peuvent définir ce champ.
6.4.2.1 Allocation FieldPossible

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

6.4.2.2 Champ NoFatChain

Le champ NoFatChain doit avoir la même définition que le même champ nommé dans le modèle Generic Primary DirectoryEntry (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 la 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 Allocation Bitmap Directory Entrée du répertoire

Dans le système de fichiers exFAT, un FAT ne décrit pas l’état d’allocation des clusters ; c’est plutôt le cas d’une bitmap d’allocation. Des bitmaps d’allocation existent dans le tas de cluster (voir la section 7.1.5) et ont des entrées de répertoire principal critiques correspondantes dans le répertoire racine (voir tableau 20).

Le champ NumberOfFats détermine le nombre d’entrées de répertoire 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 Allocation Bitmap est 1. De plus, l’entrée de répertoire Allocation Bitmap n’est valide que si elle décrit la première image bitmap d’allocation (voir la 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 si l’autre décrit la deuxième bitmap d’allocation.

Tableau 20 Allocation Bitmap DirectoryStructure

Nom du champ

Offset

(octet)

Taille

(octet)

 Commentaires
EntryType 0 1 Ce champ est obligatoire et la section 7.1.1 définit son contenu.
BitmapFlags 1 1 Ce champ est obligatoire et la 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 la section 7.1.3 définit son contenu.
DataLength 24 8 Ce champ est obligatoire et la section 7.1.4 définit son contenu.

7.1.1 Champ EntryType

Le champ EntryType doit être conforme à la définition fournie dans le modèle Generic Primary DirectoryEntry (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 Generic Primary DirectoryEntry (voir section 6.3.1.1).

Pour une entrée de répertoire Allocation Bitmap, la valeur valide pour ce champ est 1.

7.1.1.2 Champ TypeImportance

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

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

7.1.1.3 TypeCategory Field

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

7.1.1.4 Champ InUtilisation

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

7.1.2 BitmapFlags Field

Le champ BitmapFlags contient des indicateurs (voir le tableau 21).

Table 21 BitmapFlags Field Structure

Nom du champ

Offset

(bit)

Taille

(bits)

 Commentaires
BitmapIdentifier 0 1 Ce champ est obligatoire et la 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 BitmapIdentifier Field

Le champ BitmapIdentifier doit indiquer la bitmap d’allocation décrite par l’entrée de répertoire donnée. Les implémentations doivent utiliser la première image bitmap d’allocation conjointement avec la première fat et utiliser la deuxième image bitmap d’allocation conjointement avec la deuxième fat. Le champ ActiveFat décrit les bitmaps FAT et Allocation qui 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 image 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 Generic Primary DirectoryEntry (voir section 6.3.5).

Ce champ contient l’index du premier cluster de la chaîne de cluster, comme décrit dans 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 Generic Primary DirectoryEntry (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 cluster. 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 des clusters de l’index le plus bas à l’index le plus élevé (voir le tableau 22). Pour des raisons historiques, le premier cluster a l’index 2. Remarque : le premier bit de la bitmap est le bit d’ordre le plus bas du premier octet.

Table 22 Allocation Bitmap Structure

Nom du champ

Offset

(bit)

Taille

(bits)

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

.

.

.

.

.

.

.

.

.

.

.

.
BitmapEntry[ClusterCount+1] ClusterCount - 1 1

Ce champ est obligatoire et la 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é ClusterCount (DataLength * 8) – ClusterCount

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

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 dans le 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 la FAT active peut décrire le cluster correspondant comme incorrect)

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

La table en majuscules définit la conversion des caractères minuscules en majuscules. Cela est important en raison de l’entrée de répertoire Nom de fichier (voir la section 7.7) qui utilise des caractères Unicode et que le système de fichiers exFAT ne respecte pas la casse et ne respecte pas la casse. La table Up-case existe dans le tas de cluster (voir la section 7.2.5) et a une entrée de répertoire principal critique correspondante dans le répertoire racine (voir le tableau 23). Le nombre valide d’entrées de répertoire de table à la casse haute est 1.

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

Tableau 23 Structure de répertoire de table en cas de problème

Nom du champ

Offset

(octet)

Taille

(octet)

 Commentaires
EntryType 0 1 Ce champ est obligatoire et la section 7.2.1 définit son contenu.
Reserved1 1 3 Ce champ est obligatoire et son contenu est réservé.
TableChecksum 4 4 Ce champ est obligatoire et la section 7.2.2 définit son contenu.
Reserved2 8 12 Ce champ est obligatoire et son contenu est réservé.
FirstCluster 20 4 Ce champ est obligatoire et la section 7.2.3 définit son contenu.
DataLength 24 8 Ce champ est obligatoire et la 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 Generic Primary DirectoryEntry (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 Generic Primary DirectoryEntry (voir section 6.3.1.1).

Pour l’entrée de répertoire Table de la casse up, la valeur valide pour ce champ est 2.

7.2.1.2 TypeImportance Field

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

Pour l’entrée du répertoire Table de la casse up, la valeur valide pour ce champ est 0.

7.2.1.3 TypeCategory Field

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

7.2.1.4 Champ InUtilisation

Le champ InUse doit être conforme à la définition fournie dans le modèle Generic Primary DirectoryEntry (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 doivent vérifier que le contenu de ce champ est valide avant d’utiliser la table de casse up.

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 Generic Primary DirectoryEntry (voir section 6.3.5).

Ce champ contient l’index du premier cluster de la chaîne de cluster, comme décrit dans fat, qui héberge la table de casse up.

7.2.4 Champ DataLength

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

7.2.5 Table majuscule

Une table up-case 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 à monter et le champ de 2 octets représentant le caractère Unicode à caser vers le haut.

Les 128 premiers caractères Unicode ont des mappages obligatoires (voir tableau 24). Une table de casse up qui a un 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 up. Ces implémentations utilisent uniquement 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, voir section 7.7). Lors de la mise à l’échelle des noms de fichiers existants, ces implémentations ne doivent pas mettre à la hausse les caractères de la plage de mappage non obligatoire, mais les laisser intacts dans le nom de fichier mis à jour résultant (il s’agit d’un up-casing partiel). Lors de la comparaison des noms de fichiers, ces implémentations doivent traiter les noms de fichiers qui diffèrent du nom en cours de comparaison uniquement par des caractères Unicode de la plage de mappage non obligatoire comme équivalent. Bien que ces noms de fichiers soient uniquement potentiellement équivalents, ces implémentations ne peuvent pas garantir que le nom de fichier entièrement mis à jour n’entre pas en collision avec le nom en cours de comparaison.

Tableau 24 Entrées obligatoires des 128 premières tables de 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 de casse d’identité non liés à l’identité sont en gras)

Lors de la mise en forme d’un volume, les implémentations peuvent générer une table majuscule 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 casse (ce qui signifie que les caractères « minuscules » et « majuscules » sont équivalents). Les implémentations compressent une table de casse en représentant une série de mappages d’identité 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 compressée :

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

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

La possibilité de fournir une table de casse up compressée lors de la mise en forme d’un volume est facultative. Toutefois, la possibilité d’interpréter une table non compressée et une table de cas up compressée est obligatoire. La valeur du champ TableChecksum est toujours conforme à la façon dont la table up-case 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 de la casse recommandée au format compressé (voir tableau 25), pour lequel la valeur du champ TableChecksum est E619D30Dh.

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