spécification du système de fichiers exFAT

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 pour implémenter le 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 avantages des systèmes de fichiers basés sur FAT sont la simplicité et la facilité d’implémentation. Dans l’esprit de ses prédécesseurs, les implémenteurs doivent trouver le exFAT relativement simple et facile à implémenter.

  2. Activez les fichiers et les périphériques de stockage de très grande taille.

    Le système de fichiers exFAT utilise 64 bits pour décrire la taille des fichiers, ce qui permet d’activer les applications qui dépendent de fichiers volumineux. Le système de fichiers exFAT autorise également les clusters d’une taille de 32 Mo, ce qui permet de disposer d’un grand nombre de périphériques de stockage.

  3. Intégrez l’extensibilité pour une 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 de modifications de l’utilisation.

Terminologie spécifique à 1,2

Dans le contexte de cette spécification, certains termes (voir le tableau 1) transmettent 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
Arrête Cette spécification utilise le terme « doit » pour décrire un comportement qui est obligatoire.
Recommandé Cette spécification utilise le terme « doit » pour décrire un comportement recommandé, mais ne rend pas obligatoire.
Mai Cette spécification utilise le terme « peut » pour décrire un comportement qui est facultatif.
Obligatoire Ce terme décrit un champ ou une structure qu’une implémentation doit modifier et doit interpréter comme décrit dans 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 de prend en charge un champ ou une structure facultatif donné, elle est modifiée et doit 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 que l’implémentation peut modifier si nécessaire (par exemple, si elle est définie sur zéro lors de la définition de champs ou de structures environnants) et ne doit pas interpréter pour conserver une signification spécifique.
Réservé

Ce terme décrit les implémentations de champ ou de structure :

  1. Doit s’initialiser à zéro et ne doit pas être utilisé à quelque fin que ce soit

  2. Ne doit pas interpréter, sauf en cas de calcul de somme de contrôle

  3. Préserve les opérations qui modifient les champs ou structures environnantes

1,3 texte intégral des acronymes courants

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

Tableau 2 texte intégral des acronymes courants

Acronyme Texte complet
ASCII code ASCII
BIOS Système de sortie d’entrée de base
Processeur 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 Suspendre
partition Enregistrement de démarrage principal
texFAT ExFAT sécurisé pour les transactions
UTC Temps universel coordonné

Qualificateurs de champ et de structure par défaut 1,4

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

  1. Non signé

  2. Utilisez la notation décimale pour décrire les valeurs, dans le cas contraire ; Cette spécification utilise la lettre « h » après correction pour indiquer les nombres hexadécimaux et encadre les GUID entre accolades.

  3. Sont au format Little endian

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

1,5 Windows CE et TexFAT

TexFAT est une extension de exFAT qui ajoute une sémantique opérationnelle de transactions sécurisées par-dessus le système de fichiers de base. TexFAT est utilisé par Windows CE. TexFAT requiert l’utilisation des deux graisses et des bitmaps d’allocation 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é.

2 structure du volume

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 des données utilisateur. Tous les volumes exFAT contiennent quatre régions (voir le tableau 3).

Tableau 3-structure du volume

Nom de la sous-région

Offset

secteur

Taille

Sector

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.
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 la Section 3,4 définit son contenu.
Région de démarrage de sauvegarde
Secteur de démarrage de sauvegarde 12 1 Cette sous-région est obligatoire et la Section 3,1 définit son contenu.
Sauvegarder les secteurs de démarrage étendu 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 les 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 tous les deux 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 tous les deux les champs FatOffset, FatLength et NumberOfFats. Le champ NumberOfFats peut contenir uniquement les valeurs 1 et 2.

Région de données
Alignement du tas du 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 tous les deux les champs FatOffset, FatLength, NumberOfFats et ClusterHeapOffset. Les valeurs valides du champ NumberOfFats sont 1 et 2.

Segment de mémoire de cluster ClusterHeapOffset Clustercount, * 2SectorsPerClusterShift

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 tous les deux les champs ClusterHeapOffset, Clustercount, et SectorsPerClusterShift.

Espace excédentaire ClusterHeapOffset + Clustercount, * 2SectorsPerClusterShift 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 tous les deux les champs ClusterHeapOffset, Clustercount,, SectorsPerClusterShift et VolumeLength.

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

La région de démarrage principale fournit toutes les instructions d’amorçage 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. Amorcer le système d’un ordinateur à partir d’un volume exFAT.

  2. Identifiez le système de fichiers sur le volume en tant que exFAT.

  3. Découvrez l’emplacement des structures de système de fichiers exFAT.

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

Sous-régions du secteur de démarrage principal et de sauvegarde 3,1

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

Le secteur de démarrage de sauvegarde est une sauvegarde du secteur de démarrage principal et a la même structure (voir le 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 doivent vérifier leur contenu en validant leur somme de contrôle de démarrage respective et en veillant à ce que tous leurs champs soient dans leur plage de valeurs valide.

Tandis que l’opération de format initial Initialise le contenu des secteurs de démarrage principal et secondaire, les implémentations peuvent mettre à jour ces secteurs (et 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

poids

Taille

bits

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é.
Écrire 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 les deux le champ BytesPerSectorShift.

3.1.1 champ JumpBoot

Le champ JumpBoot contient l’instruction de saut pour les UC communes aux ordinateurs personnels, qui, lorsqu’il est exécuté, « déplace » le processeur pour exécuter les instructions de démarrage dans le champ de démarrage.

La valeur valide pour ce champ est (par ordre de poids faible pour octet de poids fort) 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 correspond directement à la plage d’octets que le bloc de paramètres du BIOS compressé consomme sur les volumes FAT12/16/32.

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

Champ PartitionOffset 3.1.4

Le champ PartitionOffset doit décrire le décalage de secteur relatif au support de la partition qui héberge le volume exFAT donné. Ce champ contribue au démarrage-cerclage à partir du volume à l’aide de l’extension INT 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.

Champ VolumeLength 3.1.5

Le champ VolumeLength doit décrire la taille du volume exFAT donné dans secteurs.

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

  • Au moins 220/2BytesPerSectorShift, ce qui garantit que le plus petit volume ne doit pas être 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 d’espace excédentaire est 0, la valeur de ce champ est ClusterHeapOffset + (232-11) * 2SectorsPerClusterShift.

Champ 3.1.6 FatOffset

Le champ FatOffset décrit le décalage de secteur relatif au volume du premier système FAT. Ce champ permet aux implémentations d’aligner le premier système 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 tient compte des secteurs utilisés par les régions de démarrage principales et de sauvegarde

  • Au plus ClusterHeapOffset-(FatLength * NumberOfFats), qui tient compte des secteurs consommés par le tas du cluster

Champ 3.1.7 FatLength

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

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 a suffisamment d’espace pour décrire tous les clusters dans le segment de mémoire du cluster

  • Au plus (ClusterHeapOffset-FatOffset)/NumberOfFats arrondi à l’entier le plus proche, ce qui garantit que les graisses existent avant le tas de cluster

Ce champ peut contenir une valeur dépassant sa limite inférieure (comme décrit ci-dessus) pour activer la deuxième FAT, le cas échéant, pour qu’elle soit également alignée 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 requiert, le cas échéant, n’est pas défini.

Champ 3.1.8 ClusterHeapOffset

Le champ ClusterHeapOffset doit décrire le décalage de secteur relatif au volume du segment de mémoire du 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 utilisent

  • Au maximum 232-1 ou VolumeLength-(Clustercount, * 2SectorsPerClusterShift), quel que soit le calcul le moins élevé

Champ 3.1.9 Clustercount,

Le champ Clustercount, doit décrire le nombre de clusters que contient le tas du cluster.

La valeur valide pour ce champ sera la plus petite des valeurs suivantes :

  • (VolumeLength-ClusterHeapOffset)/2SectorsPerClusterShiftarrondi à l’entier le plus proche, qui correspond exactement au nombre de clusters qui peut être compris entre le début du segment de mémoire du 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 volume FAT. Pour éviter les matières grasses extrêmement volumineuses, les implémentations peuvent contrôler le nombre de clusters dans le segment de mémoire du cluster en accroissant la taille du cluster (via le champ SectorsPerClusterShift). Cette spécification ne recommande pas plus de deux clusters de24-2 dans le segment de mémoire du cluster. Toutefois, les implémentations doivent être en mesure de gérer des volumes comportant jusqu’à 232à 11 clusters dans le segment de mémoire du cluster.

Champ 3.1.10 FirstClusterOfRootDirectory

Le champ FirstClusterOfRootDirectory doit contenir l’index de cluster du premier cluster du répertoire racine. Les implémentations doivent faire chaque effort pour placer le premier cluster du répertoire racine dans le premier cluster non défectueux après que les clusters utilisent la bitmap d’allocation et la table de cas.

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

  • Au moins 2, l’index du premier cluster dans le segment de mémoire du cluster

  • Au plus Clustercount, + 1, index du dernier cluster dans le segment de mémoire du cluster

Champ 3.1.11 VolumeSerialNumber

Le champ VolumeSerialNumber doit contenir un numéro de série unique. Cela aide les implémentations à faire la distinction entre 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 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.

Champ 3.1.12 FileSystemRevision

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

L’octet de poids fort est le numéro de révision majeur et l’octet de poids faible est le numéro de révision mineur. Par exemple, si l’octet de poids fort contient la valeur 01H et si l’octet de poids faible contient la valeur 05h, le champ FileSystemRevision décrit le numéro de révision 1,05. De même, si l’octet de poids fort contient la valeur 0Ah et si l’octet de poids faible 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 poids faible et 1 pour l’octet de poids fort

  • Au plus 99 pour l’octet de poids faible et 99 pour l’octet de poids fort

Le numéro de révision de exFAT que cette spécification décrit 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 pas monter de volumes exFAT avec un autre numéro de révision majeur. Les implémentations doivent honorer le numéro de révision mineur et ne pas effectuer d’opérations ou créer toute structure de système de fichiers non décrite dans la spécification correspondante du numéro de révision mineure donné.

Champ 3.1.13 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 du calcul de la somme de contrôle respective du démarrage ou de la région de démarrage de la sauvegarde. Lorsque vous faites référence au secteur de démarrage de sauvegarde, les implémentations traitent ce champ comme obsolète.

Tableau 5-structure de champs VolumeFlags

Nom du champ

Offset

64bits

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é.
Champ 3.1.13.1 ActiveFat

Le champ ActiveFat décrit les fichiers FAT et les bitmaps d’allocation actifs (et les implémentations doivent utiliser), comme suit :

  • 0, ce qui signifie que les premières FAT et première bitmap d’allocation sont actives

  • 1, ce qui signifie que la deuxième FAT et la deuxième bitmap d’allocation sont actives et ne sont possibles que si le champ NumberOfFats contient la valeur 2

Les implémentations considèrent la FAT inactive et la bitmap d’allocation comme obsolètes. Seules les implémentations compatibles TexFAT doivent basculer les bitmaps de la FAT et de l’allocation active (voir la Section 7,1).

Champ 3.1.13.2 VolumeDirty

Le champ VolumeDirty indique si le volume est impropre 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 en cas d’incohérence des métadonnées du système de fichiers qu’ils ne résolvent pas. Si, au moment 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 n’effacent que la valeur de ce champ à 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 affecter la valeur 1 à ce champ avant de mettre à jour les métadonnées du système de fichiers et décocher ce champ sur 0, de la même façon que l’ordre d’écriture recommandé décrit dans la Section 8,1.

Champ 3.1.13.3 MediaFailure

Le champ MediaFailure indique si une implémentation a détecté des échecs de média ou non, comme suit :

  • 0, ce qui signifie que le média d’hébergement n’a pas signalé d’échecs ou que des échecs connus sont déjà enregistrés dans le FAT en tant que clusters « incorrects »

  • 1, ce qui signifie que le média d’hébergement a signalé des échecs (c’est-à-dire qu’il a échoué des opérations de lecture ou d’écriture)

Une implémentation doit affecter la valeur 1 à ce champ dans les cas suivants :

  1. Les tentatives d’accès au support d’hébergement échouent dans une 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’ensemble du volume des défaillances de support et enregistrent tous les échecs en tant que clusters « incorrects » dans le FAT (ou résolvent les défaillances de support), vous pouvez désactiver la valeur de ce champ à 0.

Champ 3.1.13.4 ClearToZero

Le champ ClearToZero n’a pas de sens significatif 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 doivent effacer ce champ à 0 avant de modifier des structures, des répertoires ou des fichiers de système de fichiers

Champ 3.1.14 BytesPerSectorShift

Le champ BytesPerSectorShift décrira les octets par secteur exprimés comme 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 4096 octets), qui est la taille de page de la mémoire des UC communes aux ordinateurs personnels

Champ 3.1.15 SectorsPerClusterShift

Le champ SectorsPerClusterShift décrit 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 correspond à une taille de cluster de 32 Mo

Champ 3.1.16 NumberOfFats

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

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

  • 1, qui indique que le volume contient uniquement la première image FAT et la première bitmap d’allocation

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

Champ 3.1.17 DriveSelect

Le champ DriveSelect doit contenir le numéro de lecteur étendu INT 13h, qui aide à démarrer l’utilisation de ce volume à l’aide de l’extension INT 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 contiennent souvent la valeur 80h.

Champ 3.1.18 PercentInUse

Le champ PercentInUse décrit le pourcentage de clusters dans le tas de cluster 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, qui indique que le pourcentage de clusters alloués dans le tas de cluster n’est pas disponible

Les implémentations modifient la valeur de ce champ pour refléter les modifications apportées à l’allocation des clusters dans le segment de mémoire du cluster ou le remplacent par FFh.

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

Champ de démarrage 3.1.19

Le champ de démarrage doit contenir des instructions Boot-cerclage. Les implémentations peuvent remplir ce champ avec les instructions d’UC nécessaires pour le démarrage d’un système informatique. Les implémentations qui ne fournissent pas d’instructions Boot-cerclage initialisent chaque octet de ce champ sur F4h (l’instruction Halt pour les UC communes aux ordinateurs personnels) dans le cadre de leur opération de formatage.

Champ 3.1.20 BootSignature

Le champ BootSignature indique si l’intention d’un secteur donné est qu’il s’agit d’un secteur d’amorçage ou non.

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

3,2 principaux et sauvegardes-sous-régions des secteurs de démarrage étendu

Chaque secteur des principaux secteurs de démarrage étendus a la même structure ; Toutefois, chaque secteur peut contenir des instructions de démarrage distinctes (voir tableau 6). Les agents de démarrage, tels que les instructions Boot-cerclage dans le secteur de démarrage principal, les autres implémentations du BIOS 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 ou de sauvegarde étendue, les implémentations doivent vérifier leur contenu en veillant à ce que le champ ExtendedBootSignature de chaque secteur contienne sa valeur prescrite.

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

Tableau 6 structure du secteur de démarrage étendu

Nom du champ

Offset

poids

Taille

bits

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 les 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 les deux le champ BytesPerSectorShift.

3.2.1 champ ExtendedBootCode

Le champ ExtendedBootCode doit contenir des instructions Boot-cerclage. Les implémentations peuvent remplir ce champ avec les instructions d’UC nécessaires pour le démarrage d’un système informatique. Les implémentations qui ne fournissent pas d’instructions Boot-cerclage doivent initialiser chaque octet de ce champ à 00h dans le cadre de leur opération de formatage.

Champ ExtendedBootSignature 3.2.2

Le champ ExtendedBootSignature indique si l’intention d’un secteur donné est qu’il s’agit d’un secteur d’amorçage étendu.

La valeur valide pour ce champ est AA550000h. Toute autre valeur dans ce champ invalide son secteur de démarrage principal ou de sauvegarde étendu 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 principales et paramètres OEM de sauvegarde des sous-régions

La sous-région des paramètres OEM principale 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 de paramètres génériques (voir la section 3.3.2). Les fabricants peuvent dériver leurs propres structures de paramètres personnalisés à partir du modèle de paramètres génériques. Cette spécification 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 principaux paramètres OEM 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 vérifient leur contenu en validant leur somme de contrôle de démarrage respective.

Les fabricants doivent remplir les paramètres OEM principal et secondaire avec leurs propres structures de paramètres personnalisés, le cas échéant, et toute autre structure de paramètres. Les opérations de mise en forme suivantes préservent le contenu des paramètres OEM principal et de sauvegarde.

Les implémentations peuvent mettre à jour les paramètres OEM principal et secondaire 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

poids

Taille

bits

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 les deux le champ BytesPerSectorShift.

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

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

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

Le modèle de 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.

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

Nom du champ

Offset

poids

Taille

bits

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.
Champ 3.3.2.1 ParametersGuid

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és à partir de ce modèle.

3.3.3 paramètres null

La structure de paramètres null dérive du modèle de paramètres génériques (voir la section 3.3.2) et décrit un champ de paramètres inutilisé (voir le tableau 9). Lors de la création ou de la mise à jour de la structure de paramètres OEM, les implémentations doivent remplir les champs de paramètres inutilisés avec la structure de paramètres null. De même, lors de la création ou de la mise à jour de la structure de 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 de paramètres OEM.

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

Structure des paramètres null du tableau 9

Nom du champ

Offset

poids

Taille

bits

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é.
Champ 3.3.3.1 ParametersGuid

Le champ ParametersGuid doit être conforme à la définition fournie par le modèle de 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} .

Paramètres Flash 3.3.4

La structure du paramètre Flash dérive du modèle de paramètres génériques (voir la section 3.3.2) et contient des paramètres pour le média Flash (voir le tableau 10). Les fabricants de périphériques de stockage basés sur Flash peuvent remplir un champ de paramètres (de préférence le champ des paramètres [ 0 ] ) avec cette structure de paramètres. Les implémentations peuvent utiliser les informations contenues dans la structure des paramètres Flash pour optimiser les opérations d’accès pendant les opérations de lecture/écriture et pour l’alignement des structures du système de fichiers Durning la mise en forme du média.

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

Tableau 10-structure des paramètres Flash

Nom du champ

Offset

poids

Taille

bits

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 de paramètres Flash, à l’exception du champ ParametersGuid, sont valides. Toutefois, la valeur 0 indique que le champ est en fait inutile (les implémentations doivent ignorer le champ donné).

Champ 3.3.4.1 ParametersGuid

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

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

Champ 3.3.4.2 EraseBlockSize

Le champ EraseBlockSize doit décrire la taille, en octets, du bloc d’effacement du média Flash.

Champ PageSize 3.3.4.3

Le champ PageSize doit décrire la taille, en octets, de la page du média Flash.

Champ 3.3.4.4 SpareSectors

Le champ SpareSectors décrira le nombre de secteurs disponibles pour les opérations de remplacement internes du support Flash.

Champ 3.3.4.5 RandomAccessTime

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

Champ 3.3.4.6 ProgrammingTime

Le champ ProgrammingTime doit décrire le temps moyen de programmation du média Flash, en nanosecondes.

Champ 3.3.4.7 ReadCycle

Le champ ReadCycle doit décrire la durée moyenne de cycle de lecture du média Flash, en nanosecondes.

Champ 3.3.4.8 WriteCycle

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

3,4 principales et les sous-régions de somme de contrôle de démarrage 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 dans 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 la figure 1). Le modèle répétitif de la somme de contrôle de 4 octets remplit sa sous-région de somme de contrôle de démarrage respective à partir du début jusqu’à 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 principales ou de sauvegarde, les implémentations vérifient leur contenu en validant leur somme de contrôle de démarrage respective.

Tandis que l’opération de formatage initiale remplit à la fois 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 au fur et à mesure que le contenu des autres secteurs dans 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 de table d’allocation de fichiers (FAT) peut contenir jusqu’à deux graisses, 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 graisses que cette région contient. Les valeurs valides pour le champ NumberOfFats sont 1 et 2. Par conséquent, la première sous-région FAT contient toujours un volume FAT. Si le champ NumberOfFats est défini sur deux, la deuxième sous-région FAT contient également un volume FAT.

Le champ ActiveFat du champ VolumeFlags décrit le FAT qui est actif. Seul le champ VolumeFlags du secteur de démarrage principal est actif. Les implémentations traitent le FAT qui n’est pas actif comme obsolète. L’utilisation de la FAT inactive et le basculement entre les graisses sont spécifiques à l’implémentation.

4,1 première et deuxième sous-régions FAT

Un système de fichiers FAT doit décrire les chaînes de cluster dans le segment de mémoire du cluster (voir le tableau 11). Une chaîne de cluster est une série de clusters qui fournit de l’espace pour l’enregistrement du contenu de fichiers, de répertoires et d’autres structures de système de fichiers. Un système FAT représente une chaîne de clusters en tant que liste d’index de clusters à liaison unique. À 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

poids

Taille

bits

Commentaires
FatEntry [0] 0 4 Ce champ est obligatoire et la section 4.1.2 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 les 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 tous les deux les champs Clustercount,, FatLength et BytesPerSectorShift.

4.1.1 [ champ FatEntry 0 ]

Le [ champ FatEntry 0 ] doit décrire le type de support 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 FatEntry [ 1 ] champ

Le [ champ FatEntry 1 ] n’existe qu’en raison de la priorité historique et ne décrit rien d’intérêt.

La valeur valide pour ce champ est FFFFFFFFh. Les implémentations doivent initialiser 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 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 segment de mémoire du cluster. FatEntry [ 2 ] représente le premier cluster dans le segment de mémoire de cluster et FatEntry [ clustercount, + 1 ] représente le dernier cluster dans le segment de mémoire du cluster.

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

  • Entre 2 et Clustercount, + 1, inclus, qui pointe vers le FatEntry suivant dans la chaîne de clusters donnée ; le FatEntry donné ne doit pas pointer vers un FatEntry qui le précède dans la chaîne de clusters donnée

  • Exactement FFFFFFF7h, qui marque le cluster correspondant du FatEntry donné comme étant « incorrect »

  • Exactement FFFFFFFFh, qui marque le cluster correspondant du 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 clusters donnée

5 région de données

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

Sous-région du tas de cluster 5,1

La structure du tas du cluster est très simple (voir le tableau 12); chaque série de secteurs consécutives décrit un cluster, puisque le champ SectorsPerClusterShift définit. Important encore, le premier cluster du segment de mémoire de cluster possède l’index deux, qui correspond directement à l’index de FatEntry [ 2 ] .

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

Tableau 12 structure du tas de cluster

Nom du champ

Offset

secteur

Taille

Sector

Commentaires
Cluster [2] ClusterHeapOffset 2SectorsPerClusterShift

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 tous les deux les champs ClusterHeapOffset et SectorsPerClusterShift.

.

.

.

.

.

.

.

.

.

.

.

.

Cluster [Clustercount, + 1] ClusterHeapOffset + (Clustercount, – 1) * 2SectorsPerClusterShift 2SectorsPerClusterShift

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 tous les deux les champs Clustercount,, ClusterHeapOffset et SectorsPerClusterShift.

5.1.1 cluster [ 2 ] ... [Champs clustercount, + 1 du cluster ]

Chaque champ de 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 segment de mémoire du 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 sont décroissants du répertoire racine dans un mode de liaison unique.

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 sont combinées dans un jeu d’entrées de répertoire qui décrit un élément intéressant, tel qu’une structure de système de fichiers, un sous-répertoire ou un fichier.

Tableau 13-structure de répertoires

Nom du champ

Offset

poids

Taille

poids

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 est dérivé du modèle DirectoryEntry générique (voir la Section 6,2).

Modèle DirectoryEntry générique 6,2

Le modèle DirectoryEntry générique 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 comme défini dans la section 7,8 et la section 7,9). La possibilité d’interpréter le modèle DirectoryEntry générique est obligatoire.

Tableau 14 modèle DirectoryEntry générique

Nom du champ

Offset

poids

Taille

poids

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 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 du DirectoryEntry donné sont réellement 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 ensembles d’entrées de répertoire

    • Les implémentations peuvent remplacer les marqueurs de fin de répertoire en fonction des besoins

  • Entre 01H et 7Fh, qui est un marqueur d’entrée de répertoire inutilisé et les conditions suivantes s’appliquent :

    • Tous les autres champs du DirectoryEntry donné sont réellement non définis

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

    • Les implémentations peuvent remplacer les entrées d’annuaire inutilisées si nécessaire.

    • Cette plage de valeurs correspond au champ InUse (voir la section 6.2.1.4) contenant la valeur 0

  • Entre 81h et FFh, qui est une entrée de répertoire standard et les conditions suivantes s’appliquent :

    • Le contenu du champ EntryType (voir le tableau 15) détermine la disposition du reste de la structure DirectoryEntry

    • Cette plage de valeurs et uniquement cette plage de valeurs sont valides dans un jeu d’entrées de répertoire.

    • Cette plage de valeurs correspond directement au champ InUse (voir la section 6.2.1.4) contenant la valeur 1

Pour empêcher toute modification apportée au champ InUse (voir la section 6.2.1.4) provoquant par erreur un marqueur de fin de répertoire, la valeur 80h n’est pas valide.

Tableau 15-structure de champs EntryType générique

Nom du champ

Offset

64bits

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 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.
Champ TypeCode 6.2.1.1

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 la section 6.2.1.2 et la section 6.2.1.3, respectivement) identifient de façon unique le type de l’entrée de répertoire donnée.

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

Champ 6.2.1.2 TypeImportance

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

Les valeurs valides pour ce champ sont les suivantes :

  • 0, ce qui signifie que l’entrée de répertoire donnée est critique (voir la section 6.3.1.2.1 et la section 6.4.1.2.1 pour les entrées de répertoire secondaires principales critiques et critiques, respectivement)

  • 1, ce qui signifie que l’entrée de répertoire donnée est sans gravité (voir la section 6.3.1.2.2 et la section 6.4.1.2.2 pour les entrées de répertoire secondaires principales et bénignes, respectivement)

Champ TypeCategory 6.2.1.3

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

Les valeurs valides pour ce champ sont les suivantes :

  • 0, ce qui signifie que l’entrée de répertoire donnée est principale (voir la Section 6,3)

  • 1, ce qui signifie que l’entrée de répertoire donnée est secondaire (voir la Section 6,4)

Champ 6.2.1.4 InUse

Le champ InUse décrit si l’entrée de répertoire spécifiée est utilisée ou non.

Les valeurs valides pour ce champ sont 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 effectivement une entrée d’annuaire inutilisée

  • 1, ce qui signifie que l’entrée de répertoire spécifié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 segment de mémoire 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 contenues dans l’allocation de cluster associée.

La plage de valeurs valide pour ce champ est :

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

Modèle DirectoryEntry principal générique 6,3

La première entrée d’annuaire dans un jeu d’entrées de répertoire doit être une entrée d’annuaire primaire. Toutes les entrées de répertoire ultérieures, le cas échéant, dans l’ensemble d’entrées de répertoire sont des entrées de répertoire secondaires (voir la Section 6,4).

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

Toutes les structures d’entrée de répertoire principal dérivent du modèle DirectoryEntry générique principal (voir le tableau 16), qui dérive du modèle DirectoryEntry générique (voir la section 6,2).

Tableau 16 modèle DirectoryEntry générique principal

Nom du champ

Offset

poids

Taille

poids

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 DirectoryEntry générique (voir la section 6.2.1).

Champ TypeCode 6.3.1.1

Le champ TypeCode doit se conformer à la définition fournie dans le modèle DirectoryEntry générique (voir la section 6.2.1.1).

Champ 6.3.1.2 TypeImportance

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

Entrées de répertoire principal critiques 6.3.1.2.1

Les entrées d’annuaire principales critiques contiennent des informations qui sont essentielles à la gestion appropriée d’un volume exFAT. Seul le répertoire racine contient des entrées de répertoire principales critiques (les entrées de répertoire de fichier sont une exception, consultez la Section 7,4).

La définition des entrées d’annuaire principales critiques est corrélée avec le numéro de révision exFAT majeur. Les implémentations doivent prendre en charge toutes les entrées d’annuaire principales critiques et enregistrer uniquement les structures d’entrée de répertoire principales critiques définies par cette spécification.

6.3.1.2.2 les entrées de répertoire principal bénignes

Les entrées de répertoire principales bénignes contiennent des informations supplémentaires qui peuvent être utiles pour gérer un volume exFAT. N’importe quel répertoire peut contenir des entrées de répertoire principal bénignes.

La définition des entrées d’annuaire principales bénignes correspond au numéro de révision exFAT mineur. La prise en charge de toute entrée de répertoire primaire bénigne de cette spécification, ou de toute spécification ultérieure, définit est facultative. Une entrée d’annuaire principal Bénin non reconnue rend l’ensemble de l’entrée de répertoire non reconnue (au-delà de la définition des modèles d’entrée de répertoire applicables).

Champ 6.3.1.3 TypeCategory

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

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

Champ 6.3.1.4 InUse

Le champ InUse doit se conformer à la définition fournie dans le modèle DirectoryEntry générique (voir la 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 d’annuaire primaire donnée. Ces entrées de répertoire secondaires, ainsi que l’entrée d’annuaire primaire donnée, constituent le jeu 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 d’annuaire primaire est la seule entrée dans le jeu d’entrées de répertoire

  • Au plus 255, ce qui signifie que les 255 entrées de répertoire suivantes et cette entrée d’annuaire principale comprennent le jeu d’entrées de répertoire

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

Champ 6.3.3 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 une autre entrée de répertoire dans le jeu d’entrées de répertoire donné.

Les structures d’entrée de répertoire principales 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;
}

Champ 6.3.4 GeneralPrimaryFlags

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

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

Tableau 17 structure des champs GeneralPrimaryFlags génériques

Nom du champ

Offset

64bits

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.
Champ 6.3.4.1 AllocationPossible

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

Les valeurs valides pour ce champ sont les suivantes :

  • 0, ce qui signifie qu’une allocation associée de clusters n’est pas possible et que les champs FirstCluster et DataLength sont réellement non 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 définis

Champ 6.3.4.2 NoFatChain

Le champ NoFatChain indique si la FAT active décrit la chaîne de cluster de l’allocation donnée.

Les valeurs valides pour ce champ sont 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 que 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 principales critiques qui dérivent de ce modèle redéfinissent le champ GeneralPrimaryFlags, les entrées FAT correspondantes pour toute chaîne de cluster d’allocation associée sont valides.

Champ 6.3.5 FirstCluster

Le champ FirstCluster doit être conforme à la définition fournie dans le modèle DirectoryEntry générique (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 principales critiques qui dérivent de ce modèle peuvent redéfinir les champs FirstCluster et DataLength. Les 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.

Champ 6.3.6 DataLength

Le champ DataLength doit se conformer à la définition fournie dans le modèle DirectoryEntry générique (voir la 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 avoir la valeur zéro.

Les structures d’entrée de répertoire principales critiques qui dérivent de ce modèle peuvent redéfinir les champs FirstCluster et DataLength. Les 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.

Modèle DirectoryEntry secondaire générique 6,4

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

La définition des entrées d’annuaire secondaire critiques et bénignes est corrélée avec le numéro de révision exFAT mineur. La prise en charge d’une entrée d’annuaire secondaire critique ou Bénin dans cette spécification, ou sur les spécifications suivantes, définit est facultative.

Toutes les structures d’entrée de répertoire secondaires dérivent du modèle DirectoryEntry secondaire générique (voir le tableau 18), qui dérive du modèle DirectoryEntry générique (voir la section 6,2).

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

Nom du champ

Offset

poids

Taille

poids

Commentaires
EntryType 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 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.

Champ 6.4.1 EntryType

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

Champ TypeCode 6.4.1.1

Le champ TypeCode doit se conformer à la définition fournie dans le modèle DirectoryEntry générique (voir la section 6.2.1.1).

Champ 6.4.1.2 TypeImportance

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

Entrées d’annuaire secondaire critique 6.4.1.2.1

Les entrées de répertoire secondaires critiques contiennent des informations qui sont essentielles à la gestion correcte de l’ensemble d’entrées de répertoire qui les contient. Bien que la prise en charge d’une entrée d’annuaire secondaire critique spécifique soit facultative, une entrée de répertoire critique non reconnue rend le jeu d’entrées de répertoire entier non reconnu (au-delà de la définition des modèles d’entrée de répertoire applicables).

Toutefois, si un jeu d’entrées de répertoire contient au moins une entrée d’annuaire 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 d’annuaire et non pas les données qu’une allocation associée à une entrée d’annuaire dans le jeu d’entrées de répertoire contient (les entrées de répertoire de fichiers sont une 7,4exception.

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

Les entrées de répertoire secondaires bénignes contiennent des informations supplémentaires qui peuvent être utiles pour gérer l’ensemble d’entrées de répertoire qui les contient. La prise en charge d’une entrée de répertoire secondaire inoffensif spécifique est facultative. Les entrées d’annuaire secondaire non reconnues n’affichent pas l’intégralité 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.

Champ 6.4.1.3 TypeCategory

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

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

Champ 6.4.1.4 InUse

Le champ InUse doit se conformer à la définition fournie dans le modèle DirectoryEntry générique (voir la section 6.2.1.4).

6.4.2 champ GeneralSecondaryFlags

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

Tableau 19-structure de champs GeneralSecondaryFlags générique

Nom du champ

Offset

64bits

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.
Champ 6.4.2.1 AllocationPossible

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

Champ 6.4.2.2 NoFatChain

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

Champ 6.4.3 FirstCluster

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

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

Champ 6.4.4 DataLength

Le champ DataLength doit se conformer à la définition fournie dans le modèle DirectoryEntry générique (voir la 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 avoir la valeur zéro.

7 définitions d’entrée de répertoire

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 de l’allocation de bitmap

Dans le système de fichiers exFAT, FAT ne décrit pas l’état d’allocation des clusters ; au lieu de cela, une bitmap d’allocation. Les bitmaps d’allocation existent dans le segment de mémoire du cluster (voir la section 7.1.5) et ont des entrées d’annuaire principales critiques correspondantes dans le répertoire racine (voir tableau 20).

Le champ NumberOfFats détermine le nombre d’entrées de répertoires de la 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 l’arborescence de la bitmap d’allocation est 1. En outre, l’entrée de répertoire de l’image bitmap d’allocation est valide uniquement si elle décrit la première 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 l’annuaire de la bitmap d’allocation est 2. En outre, les deux entrées de répertoire de la bitmap d’allocation sont valides uniquement si l’une d’elles décrit la première bitmap d’allocation et l’autre décrit la deuxième bitmap d’allocation.

Table 20 bitmap d’allocation, structure DirectoryEntry

Nom du champ

Offset

poids

Taille

poids

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 le chapitre 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 DirectoryEntry principal générique (voir la section 6.3.1).

7.1.1.1 champ TypeCode

Le champ TypeCode doit se conformer à la définition fournie dans le modèle DirectoryEntry principal générique (voir la section 6.3.1.1).

Pour une entrée d’annuaire d’une bitmap d’allocation, 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 DirectoryEntry principal générique (voir la section 6.3.1.2).

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

Champ 7.1.1.3 TypeCategory

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

Champ 7.1.1.4 InUse

Le champ InUse doit se conformer à la définition fournie dans le modèle DirectoryEntry principal générique (voir la section 6.3.1.4).

7.1.2 champ BitmapFlags

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

Tableau 21-structure de champs BitmapFlags

Nom du champ

Offset

64bits

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é.
Champ 7.1.2.1 BitmapIdentifier

Le champ BitmapIdentifier indique la bitmap d’allocation décrite par l’entrée d’annuaire donnée. Les implémentations utilisent la première bitmap d’allocation conjointement avec le premier système FAT et utilisent la deuxième bitmap d’allocation conjointement avec la deuxième FAT. Le champ ActiveFat décrit les fichiers FAT et les bitmaps d’allocation actifs.

Les valeurs valides pour ce champ sont 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

Champ FirstCluster 7.1.3

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

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

Champ 7.1.4 DataLength

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

Bitmap d’allocation 7.1.5

Une bitmap d’allocation enregistre l’état d’allocation des clusters dans le segment de mémoire du 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 les clusters de l’index le plus bas au plus haut (voir le tableau 22). Pour des raisons historiques, le premier cluster possède l’index 2. Remarque : le premier bit de la bitmap est le bit d’ordre le plus bas du premier octet.

Tableau 22 structure d’une bitmap d’allocation

Nom du champ

Offset

64bits

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 la section 7.1.5.1 définit son contenu.

Remarque : les secteurs de démarrage principal et de sauvegarde contiennent tous les 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 les 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 segment de mémoire du cluster. BitmapEntry [ 2 ] représente le premier cluster dans le segment de mémoire de cluster et BitmapEntry [ clustercount, + 1 ] représente le dernier cluster dans le segment de mémoire du cluster.

Les valeurs valides pour ces champs doivent être :

  • 0, qui décrit le cluster correspondant comme étant disponible pour l’allocation

  • 1, qui décrit le cluster correspondant comme n’étant pas 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 étant incorrecte)

7,2 entrée du répertoire de la table de cas

La table up-case définit la conversion des caractères minuscules en majuscules. Cela est important en raison de l’entrée de répertoire de nom de fichier (voir la section 7,7) en utilisant des caractères Unicode et le système de fichiers exFAT qui ne respecte pas la casse et conserve la casse. La table de cas existe dans le segment de mémoire du cluster (voir la section 7.2.5) et a une entrée d’annuaire principale critique correspondante dans le répertoire racine (voir le tableau 23). Le nombre valide d’entrées du répertoire de la table de cas d’usage est de 1.

En raison de la relation entre les noms de table et de fichier, les implémentations ne doivent pas modifier la table de cas, sauf suite à des opérations de format.

Tableau 23 structure de la table de cas

Nom du champ

Offset

poids

Taille

poids

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 DirectoryEntry principal générique (voir la section 6.3.1).

Champ TypeCode 7.2.1.1

Le champ TypeCode doit se conformer à la définition fournie dans le modèle DirectoryEntry principal générique (voir la section 6.3.1.1).

Pour l’entrée d’annuaire de la table de cas, la valeur valide pour ce champ est 2.

Champ TypeImportance 7.2.1.2.

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

Pour l’entrée d’annuaire de la table de cas, la valeur valide pour ce champ est 0.

Champ 7.2.1.3 TypeCategory

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

Champ 7.2.1.4 InUse

Le champ InUse doit se conformer à la définition fournie dans le modèle DirectoryEntry principal générique (voir la section 6.3.1.4).

7.2.2 champ TableChecksum

Le champ TableChecksum contient la somme de contrôle de la table up-case (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 cas.

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 DirectoryEntry principal générique (voir la section 6.3.5).

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

7.2.4 champ DataLength

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

7.2.5-table de cas

Une table de cas 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 cas, qui représente le caractère Unicode à faire figurer, et le champ de 2 octets représentant le caractère Unicode en cours.

Les 128 premiers caractères Unicode ont des mappages obligatoires (voir le tableau 24). Une table de cas 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 ne prennent en charge que les caractères de la plage de mappage obligatoire peuvent ignorer les mappages du reste de la table de cas. Ces implémentations utilisent uniquement des caractères de la plage de mappage obligatoire lors de la création ou de la modification des noms de fichiers (via l’entrée de répertoire de nom de fichier, consultez la Section 7,7). Lors de la mise en majuscule des noms de fichiers existants, ces implémentations ne doivent pas respecter les caractères de la plage de mappage non obligatoire, mais les laissent intactes dans le nom de fichier 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 la comparaison uniquement par les caractères Unicode de la plage de mappage non obligatoire comme équivalent. Bien que ces noms de fichiers soient uniquement équivalents, ces implémentations ne peuvent pas garantir que le nom de fichier entièrement en fonction de la casse n’entre pas en conflit avec le nom sous la comparaison.

Tableau 24 premières entrées de table de cas de première 128 obligatoires

Index de table Entrées de la 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 cas de non-identité sont en gras)

Lors de la mise en forme d’un volume, les implémentations peuvent générer une table de cas 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 cas en représentant une série de mappages d’identité avec la valeur FFFFh suivi du nombre de mappages d’identité.

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

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

Les deux premières entrées indiquent que les 97 premiers caractères (61h) (de 0000h à 0060h) 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 cas 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 de cas compressée est obligatoire. La valeur du champ TableChecksum est toujours conforme à la façon dont la table de cas 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 cas recommandée au format compressé (voir le tableau 25), pour lequel la valeur du champ TableChecksum est E619D30Dh.

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