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 à 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).
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.
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.
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.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.
Sont non signés
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
Sont au format little-endian
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 :
Sangle de démarrage d’un système informatique à partir d’un volume exFAT.
Identifiez le système de fichiers sur le volume comme exFAT.
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 :
Le média d’hébergement échoue à des tentatives d’accès à n’importe quelle région dans le volume
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 :
Principal critique
Bitmap d’allocation (section 7.1)
Up-case Table (Section 7.2)
Étiquette de volume (section 7.3)
Fichier (section 7.4)
Primaire bénigne
GUID de volume (section 7.5)
TexFAT Padding (section 7.10)
Secondaire critique
Extension de flux (section 7.6)
Nom de fichier (section 7.7)
Secondaire sans gravité
Extension fournisseur (section 7.8)
Allocation du fournisseur (section 7.9)
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é.
7.2.5.1 Table de cas up recommandée
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).
Tableau 25 Table majuscule recommandée au format compressé
Décalage brut | + 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 |
0080h | 0080h | 0081h | 0082h | 0083h | 0084h | 0085h | 0086h | 0087h |
0088h | 0088h | 0089h | 008Ah | 008Bh | 008Ch | 008Dh | 008Eh | 008Fh |
0090h | 0090h | 0091h | 0092h | 0093h | 0094h | 0095h | 0096h | 0097h |
0098h | 0098h | 0099h | 009Ah | 009Bh | 009Ch | 009Dh | 009Eh | 009Fh |
00A0h | 00A0h | 00A1h | 00A2h | 00A3h | 00A4h | 00A5h | 00A6h | 00A7h |
00A8h | 00A8h | 00A9h | 00AAh | 00ABh | 00ACh | 00ADh | 00AEh | 00AFh |
00B0h | 00B0h | 00B1h | 00B2h | 00B3h | 00B4h | 00B5h | 00B6h | 00B7h |
00B8h | 00B8h | 00B9h | 00BAh | 00Bh | 00BCh | 00BDh | 00BEh | 00BFh |
00C0h | 00C0h | 00C1h | 00C2h | 00C3h | 00C4h | 00C5h | 00C6h | 00C7h |
00C8h | 00C8h | 00C9h | 00CAh | 00CBh | 00CCh | 00CDh | 00CEh | 00CFh |
00D0h | 00D0h | 00D1h | 00D2h | 00D3h | 00D4h | 00D5h | 00D6h | 00D7h |
00D8h | 00D8h | 00D9h | 00DAh | 00DBh | 00DCh | 00 DDh | 00DEh | 00DFh |
00E0h | 00C0h | 00C1h | 00C2h | 00C3h | 00C4h | 00C5h | 00C6h | 00C7h |
00E8h | 00C8h | 00C9h | 00CAh | 00CBh | 00CCh | 00CDh | 00CEh | 00CFh |
00F0h | 00D0h | 00D1h | 00D2h | 00D3h | 00D4h | 00D5h | 00D6h | 00F7h |
00F8h | 00D8h | 00D9h | 00DAh | 00DBh | 00DCh | 00 DDh | 00DEh | 0178h |
0100h | 0100h | 0100h | 0102h | 0102h | 0104h | 0104h | 0106h | 0106h |
0108h | 0108h | 0108h | 010Ah | 010Ah | 010Ch | 010Ch | 010Eh | 010Eh |
0110h | 0110h | 0110h | 0112h | 0112h | 0114h | 0114h | 0116h | 0116h |
0118h | 0118h | 0118h | 011Ah | 011Ah | 011Ch | 011Ch | 011Eh | 011Eh |
0120h | 0120h | 0120h | 0122h | 0122h | 0124h | 0124h | 0126h | 0126h |
0128h | 0128h | 0128h | 012Ah | 012Ah | 012Ch | 012Ch | 012Eh | 012Eh |
0130h | 0130h | 0131h | 0132h | 0132h | 0134h | 0134h | 0136h | 0136h |
0138h | 0138h | 0139h | 0139h | 013Bh | 013Bh | 013Dh | 013Dh | 013Fh |
0140h | 013Fh | 0141h | 0141h | 0143h | 0143h | 0145h | 0145h | 0147h |
0148h | 0147h | 0149h | 014Ah | 014Ah | 014Ch | 014Ch | 014Eh | 014Eh |
0150h | 0150h | 0150h | 0152h | 0152h | 0154h | 0154h | 0156h | 0156h |
0158h | 0158h | 0158h | 015Ah | 015Ah | 015Ch | 015Ch | 015Eh | 015Eh |
0160h | 0160h | 0160h | 0162h | 0162h | 0164h | 0164h | 0166h | 0166h |
0168h | 0168h | 0168h | 016Ah | 016Ah | 016Ch | 016Ch | 016Eh | 016Eh |
0170h | 0170h | 0170h | 0172h | 0172h | 0174h | 0174h | 0176h | 0176h |
0178h | 0178h | 0179h | 0179h | 017Bh | 017Bh | 017Dh | 017Dh | 017Fh |
0180h | 0243h | 0181h | 0182h | 0182h | 0184h | 0184h | 0186h | 0187h |
0188h | 0187h | 0189h | 018Ah | 018Bh | 018Bh | 018Dh | 018Eh | 018Fh |
0190h | 0190h | 0191h | 0191h | 0193h | 0194h | 01F6h | 0196h | 0197h |
0198h | 0198h | 0198h | 023Dh | 019Bh | 019Ch | 019Dh | 0220h | 019Fh |
01A0h | 01A0h | 01A0h | 01A2h | 01A2h | 01A4h | 01A4h | 01A6h | 01A7h |
01A8h | 01A7h | 01A9h | 01AAh | 01ABh | 01ACh | 01ACh | 01AEh | 01AFh |
01B0h | 01AFh | 01B1h | 01B2h | 01B3h | 01B3h | 01B5h | 01B5h | 01B7h |
01B8h | 01B8h | 01B8h | 01BAh | 01BBh | 01BCh | 01BCh | 01BEh | 01F7h |
01C0h | 01C0h | 01C1h | 01C2h | 01C3h | 01C4h | 01C5h | 01C4h | 01C7h |
01C8h | 01C8h | 01C7h | 01CAh | 01CBh | 01CAh | 01CDh | 01CDh | 01CFh |
01D0h | 01CFh | 01D1h | 01D1h | 01D3h | 01D3h | 01D5h | 01D5h | 01D7h |
01D8h | 01D7h | 01D9h | 01D9h | 01DBh | 01DBh | 018Eh | 01DEh | 01DEh |
01E0h | 01E0h | 01E0h | 01E2h | 01E2h | 01E4h | 01E4h | 01E6h | 01E6h |
01E8h | 01E8h | 01E8h | 01EAh | 01EAh | 01ECh | 01ECh | 01EEh | 01EEh |
01F0h | 01F0h | 01F1h | 01F2h | 01F1h | 01F4h | 01F4h | 01F6h | 01F7h |
01F8h | 01F8h | 01F8h | 01FAh | 01FAh | 01FCh | 01FCh | 01FEh | 01FEh |
0200h | 0200h | 0200h | 0202h | 0202h | 0204h | 0204h | 0206h | 0206h |
0208h | 0208h | 0208h | 020Ah | 020Ah | 020Ch | 020Ch | 020Eh | 020Eh |
0210h | 0210h | 0210h | 0212h | 0212h | 0214h | 0214h | 0216h | 0216h |
0218h | 0218h | 0218h | 021Ah | 021Ah | 021Ch | 021Ch | 021Eh | 021Eh |
0220h | 0220h | 0221h | 0222h | 0222h | 0224h | 0224h | 0226h | 0226h |
0228h | 0228h | 0228h | 022Ah | 022Ah | 022Ch | 022Ch | 022Eh | 022Eh |
0230h | 0230h | 0230h | 0232h | 0232h | 0234h | 0235h | 0236h | 0237h |
0238h | 0238h | 0239h | 2C65h | 023Bh | 023Bh | 023Dh | 2C66h | 023Fh |
0240h | 0240h | 0241h | 0241h | 0243h | 0244h | 0245h | 0246h | 0246h |
0248h | 0248h | 0248h | 024Ah | 024Ah | 024Ch | 024Ch | 024Eh | 024Eh |
0250h | 0250h | 0251h | 0252h | 0181h | 0186h | 0255h | 0189h | 018Ah |
0258h | 0258h | 018Fh | 025Ah | 0190h | 025Ch | 025Dh | 025Eh | 025Fh |
0260h | 0193h | 0261h | 0262h | 0194h | 0264h | 0265h | 0266h | 0267h |
0268h | 0197h | 0196h | 026Ah | 2C62h | 026Ch | 026Dh | 026Eh | 019Ch |
0270h | 0270h | 0271h | 019Dh | 0273h | 0274h | 019Fh | 0276h | 0277h |
0278h | 0278h | 0279h | 027Ah | 027Bh | 027Ch | 2C64h | 027Eh | 027Fh |
0280h | 01A6h | 0281h | 0282h | 01A9h | 0284h | 0285h | 0286h | 0287h |
0288h | 01AEh | 0244h | 01B1h | 01B2h | 0245h | 028Dh | 028Eh | 028Fh |
0290h | 0290h | 0291h | 01B7h | 0293h | 0294h | 0295h | 0296h | 0297h |
0298h | 0298h | 0299h | 029Ah | 029Bh | 029Ch | 029Dh | 029Eh | 029Fh |
02A0h | 02A0h | 02A1h | 02A2h | 02A3h | 02A4h | 02A5h | 02A6h | 02A7h |
02A8h | 02A8h | 02A9h | 02AAh | 02ABh | 02ACh | 02ADh | 02AEh | 02AFh |
02B0h | 02B0h | 02B1h | 02B2h | 02B3h | 02B4h | 02B5h | 02B6h | 02B7h |
02B8h | 02B8h | 02B9h | 02BAh | 02Bh | 02BCh | 02BDh | 02BEh | 02BFh |
02C0h | 02C0h | 02C1h | 02C2h | 02C3h | 02C4h | 02C5h | 02C6h | 02C7h |
02C8h | 02C8h | 02C9h | 02CAh | 02CBh | 02CCh | 02CDh | 02CEh | 02CFh |
02D0h | 02D0h | 02D1h | 02D2h | 02D3h | 02D4h | 02D5h | 02D6h | 02D7h |
02D8h | 02D8h | 02D9h | 02DAh | 02DBh | 02DCh | 02DDh | 02DEh | 02DFh |
02E0h | 02E0h | 02E1h | 02E2h | 02E3h | 02E4h | 02E5h | 02E6h | 02E7h |
02E8h | 02E8h | 02E9h | 02EAh | 02EBh | 02ECh | 02EDh | 02EEh | 02EFh |
02F0h | 02F0h | 02F1h | 02F2h | 02F3h | 02F4h | 02F5h | 02F6h | 02F7h |
02F8h | 02F8h | 02F9h | 02FAh | 02FBh | 02FCh | 02FDh | 02FEh | 02Fh |
0300h | 0300h | 0301h | 0302h | 0303h | 0304h | 0305h | 0306h | 0307h |
0308h | 0308h | 0309h | 030Ah | 030Bh | 030Ch | 030Dh | 030Eh | 030Fh |
0310h | 0310h | 0311h | 0312h | 0313h | 0314h | 0315h | 0316h | 0317h |
0318h | 0318h | 0319h | 031Ah | 031Bh | 031Ch | 031Dh | 031Eh | 031Fh |
0320h | 0320h | 0321h | 0322h | 0323h | 0324h | 0325h | 0326h | 0327h |
0328h | 0328h | 0329h | 032Ah | 032Bh | 032Ch | 032Dh | 032Eh | 032Fh |
0330h | 0330h | 0331h | 0332h | 0333h | 0334h | 0335h | 0336h | 0337h |
0338h | 0338h | 0339h | 033Ah | 033Bh | 033Ch | 033Dh | 033Eh | 033Fh |
0340h | 0340h | 0341h | 0342h | 0343h | 0344h | 0345h | 0346h | 0347h |
0348h | 0348h | 0349h | 034Ah | 034Bh | 034Ch | 034Dh | 034Eh | 034Fh |
0350h | 0350h | 0351h | 0352h | 0353h | 0354h | 0355h | 0356h | 0357h |
0358h | 0358h | 0359h | 035Ah | 035Bh | 035Ch | 035Dh | 035Eh | 035Fh |
0360h | 0360h | 0361h | 0362h | 0363h | 0364h | 0365h | 0366h | 0367h |
0368h | 0368h | 0369h | 036Ah | 036Bh | 036Ch | 036Dh | 036Eh | 036Fh |
0370h | 0370h | 0371h | 0372h | 0373h | 0374h | 0375h | 0376h | 0377h |
0378h | 0378h | 0379h | 037Ah | 03FDh | 03FEh | 03FFh | 037Eh | 037Fh |
0380h | 0380h | 0381h | 0382h | 0383h | 0384h | 0385h | 0386h | 0387h |
0388h | 0388h | 0389h | 038Ah | 038Bh | 038Ch | 038Dh | 038Eh | 038Fh |
0390h | 0390h | 0391h | 0392h | 0393h | 0394h | 0395h | 0396h | 0397h |
0398h | 0398h | 0399h | 039Ah | 039Bh | 039Ch | 039Dh | 039Eh | 039Fh |
03A0h | 03A0h | 03A1h | 03A2h | 03A3h | 03A4h | 03A5h | 03A6h | 03A7h |
03A8h | 03A8h | 03A9h | 03AAh | 03ABh | 0386h | 0388h | 0389h | 038Ah |
03B0h | 03B0h | 0391h | 0392h | 0393h | 0394h | 0395h | 0396h | 0397h |
03B8h | 0398h | 0399h | 039Ah | 039Bh | 039Ch | 039Dh | 039Eh | 039Fh |
03C0h | 03A0h | 03A1h | 03A3h | 03A3h | 03A4h | 03A5h | 03A6h | 03A7h |
03C8h | 03A8h | 03A9h | 03AAh | 03ABh | 038Ch | 038Eh | 038Fh | 03CFh |
03D0h | 03D0h | 03D1h | 03D2h | 03D3h | 03D4h | 03D5h | 03D6h | 03D7h |
03D8h | 03D8h | 03D8h | 03DAh | 03DAh | 03DCh | 03DCh | 03DEh | 03DEh |
03E0h | 03E0h | 03E0h | 03E2h | 03E2h | 03E4h | 03E4h | 03E6h | 03E6h |
03E8h | 03E8h | 03E8h | 03EAh | 03EAh | 03ECh | 03ECh | 03EEh | 03EEh |
03F0h | 03F0h | 03F1h | 03F9h | 03F3h | 03F4h | 03F5h | 03F6h | 03F7h |
03F8h | 03F7h | 03F9h | 03FAh | 03FAh | 03FCh | 03FDh | 03FEh | 03Fh |
0400h | 0400h | 0401h | 0402h | 0403h | 0404h | 0405h | 0406h | 0407h |
0408h | 0408h | 0409h | 040Ah | 040Bh | 040Ch | 040Dh | 040Eh | 040Fh |
0410h | 0410h | 0411h | 0412h | 0413h | 0414h | 0415h | 0416h | 0417h |
0418h | 0418h | 0419h | 041Ah | 041Bh | 041Ch | 041Dh | 041Eh | 041Fh |
0420h | 0420h | 0421h | 0422h | 0423h | 0424h | 0425h | 0426h | 0427h |
0428h | 0428h | 0429h | 042Ah | 042Bh | 042Ch | 042Dh | 042Eh | 042Fh |
0430h | 0410h | 0411h | 0412h | 0413h | 0414h | 0415h | 0416h | 0417h |
0438h | 0418h | 0419h | 041Ah | 041Bh | 041Ch | 041Dh | 041Eh | 041Fh |
0440h | 0420h | 0421h | 0422h | 0423h | 0424h | 0425h | 0426h | 0427h |
0448h | 0428h | 0429h | 042Ah | 042Bh | 042Ch | 042Dh | 042Eh | 042Fh |
0450h | 0400h | 0401h | 0402h | 0403h | 0404h | 0405h | 0406h | 0407h |
0458h | 0408h | 0409h | 040Ah | 040Bh | 040Ch | 040Dh | 040Eh | 040Fh |
0460h | 0460h | 0460h | 0462h | 0462h | 0464h | 0464h | 0466h | 0466h |
0468h | 0468h | 0468h | 046Ah | 046Ah | 046Ch | 046Ch | 046Eh | 046Eh |
0470h | 0470h | 0470h | 0472h | 0472h | 0474h | 0474h | 0476h | 0476h |
0478h | 0478h | 0478h | 047Ah | 047Ah | 047Ch | 047Ch | 047Eh | 047Eh |
0480h | 0480h | 0480h | 0482h | 0483h | 0484h | 0485h | 0486h | 0487h |
0488h | 0488h | 0489h | 048Ah | 048Ah | 048Ch | 048Ch | 048Eh | 048Eh |
0490h | 0490h | 0490h | 0492h | 0492h | 0494h | 0494h | 0496h | 0496h |
0498h | 0498h | 0498h | 049Ah | 049Ah | 049Ch | 049Ch | 049Eh | 049Eh |
04A0h | 04A0h | 04A0h | 04A2h | 04A2h | 04A4h | 04A4h | 04A6h | 04A6h |
04A8h | 04A8h | 04A8h | 04AAh | 04AAh | 04ACh | 04ACh | 04AEh | 04AEh |
04B0h | 04B0h | 04B0h | 04B2h | 04B2h | 04B4h | 04B4h | 04B6h | 04B6h |
04B8h | 04B8h | 04B8h | 04BAh | 04BAh | 04BCh | 04BCh | 04BEh | 04BEh |
04C0h | 04C0h | 04C1h | 04C1h | 04C3h | 04C3h | 04C5h | 04C5h | 04C7h |
04C8h | 04C7h | 04C9h | 04C9h | 04CBh | 04CBh | 04CDh | 04CDh | 04C0h |
04D0h | 04D0h | 04D0h | 04D2h | 04D2h | 04D4h | 04D4h | 04D6h | 04D6h |
04D8h | 04D8h | 04D8h | 04DAh | 04DAh | 04DCh | 04DCh | 04DEh | 04DEh |
04E0h | 04E0h | 04E0h | 04E2h | 04E2h | 04E4h | 04E4h | 04E6h | 04E6h |
04E8h | 04E8h | 04E8h | 04EAh | 04EAh | 04ECh | 04ECh | 04EEh | 04EEh |
04F0h | 04F0h | 04F0h | 04F2h | 04F2h | 04F4h | 04F4h | 04F6h | 04F6h |
04F8h | 04F8h | 04F8h | 04FAh | 04FAh | 04FCh | 04FCh | 04FEh | 04FEh |
0500h | 0500h | 0500h | 0502h | 0502h | 0504h | 0504h | 0506h | 0506h |
0508h | 0508h | 0508h | 050Ah | 050Ah | 050Ch | 050Ch | 050Eh | 050Eh |
0510h | 0510h | 0510h | 0512h | 0512h | 0514h | 0515h | 0516h | 0517h |
0518h | 0518h | 0519h | 051Ah | 051Bh | 051Ch | 051Dh | 051Eh | 051Fh |
0520h | 0520h | 0521h | 0522h | 0523h | 0524h | 0525h | 0526h | 0527h |
0528h | 0528h | 0529h | 052Ah | 052Bh | 052Ch | 052Dh | 052Eh | 052Fh |
0530h | 0530h | 0531h | 0532h | 0533h | 0534h | 0535h | 0536h | 0537h |
0538h | 0538h | 0539h | 053Ah | 053Bh | 053Ch | 053Dh | 053Eh | 053Fh |
0540h | 0540h | 0541h | 0542h | 0543h | 0544h | 0545h | 0546h | 0547h |
0548h | 0548h | 0549h | 054Ah | 054Bh | 054Ch | 054Dh | 054Eh | 054Fh |
0550h | 0550h | 0551h | 0552h | 0553h | 0554h | 0555h | 0556h | 0557h |
0558h | 0558h | 0559h | 055Ah | 055Bh | 055Ch | 055Dh | 055Eh | 055Fh |
0560h | 0560h | 0531h | 0532h | 0533h | 0534h | 0535h | 0536h | 0537h |
0568h | 0538h | 0539h | 053Ah | 053Bh | 053Ch | 053Dh | 053Eh | 053Fh |
0570h | 0540h | 0541h | 0542h | 0543h | 0544h | 0545h | 0546h | 0547h |
0578h | 0548h | 0549h | 054Ah | 054Bh | 054Ch | 054Dh | 054Eh | 054Fh |
0580h | 0550h | 0551h | 0552h | 0553h | 0554h | 0555h | 0556h | FFFFh |
0588h | 17F6h | 2C63h | 1D7Eh | 1D7Fh | 1D80h | 1D81h | 1D82h | 1D83h |
0590h | 1D84h | 1D85h | 1D86h | 1D87h | 1D88h | 1D89h | 1D8Ah | 1D8Bh |
0598h | 1D8Ch | 1D8Dh | 1D8Eh | 1D8Fh | 1D90h | 1D91h | 1D92h | 1D93h |
05A0h | 1D94h | 1D95h | 1D96h | 1D97h | 1D98h | 1D99h | 1D9Ah | 1D9Bh |
05A8h | 1D9Ch | 1D9Dh | 1D9Eh | 1D9Fh | 1DA0h | 1DA1h | 1DA2h | 1DA3h |
05B0h | 1DA4h | 1DA5h | 1DA6h | 1DA7h | 1DA8h | 1DA9h | 1DAAh | 1DABh |
05B8h | 1DACh | 1DADh | 1DAEh | 1DAFh | 1DB0h | 1DB1h | 1DB2h | 1DB3h |
05C0h | 1DB4h | 1DB5h | 1DB6h | 1DB7h | 1DB8h | 1DB9h | 1DBAh | 1DBBh |
05C8h | 1DBCh | 1DBDh | 1DBEh | 1DBFh | 1DC0h | 1DC1h | 1DC2h | 1DC3h |
05D0h | 1DC4h | 1DC5h | 1DC6h | 1DC7h | 1DC8h | 1DC9h | 1DCAh | 1DCBh |
05D8h | 1DCCh | 1DCDh | 1DCEh | 1DCFh | 1DD0h | 1DD1h | 1DD2h | 1DD3h |
05E0h | 1DD4h | 1DD5h | 1DD6h | 1DD7h | 1DD8h | 1DD9h | 1DDAh | 1DDBh |
05E8h | 1DDCh | 1DDDh | 1DDEh | 1DDFh | 1DE0h | 1DE1h | 1DE2h | 1DE3h |
05F0h | 1DE4h | 1DE5h | 1DE6h | 1DE7h | 1DE8h | 1DE9h | 1DEAh | 1DEBh |
05F8h | 1DECh | 1DEDh | 1DEEh | 1DEFh | 1DF0h | 1DF1h | 1DF2h | 1DF3h |
0600h | 1DF4h | 1DF5h | 1DF6h | 1DF7h | 1DF8h | 1DF9h | 1DFAh | 1DFBh |
0608h | 1DFCh | 1DFDh | 1DFEh | 1DFFh | 1E00h | 1E00h | 1E02h | 1E02h |
0610h | 1E04h | 1E04h | 1E06h | 1E06h | 1E08h | 1E08h | 1E0Ah | 1E0Ah |
0618h | 1E0Ch | 1E0Ch | 1E0Eh | 1E0Eh | 1E10h | 1E10h | 1E12h | 1E12h |
0620h | 1E14h | 1E14h | 1E16h | 1E16h | 1E18h | 1E18h | 1E1Ah | 1E1Ah |
0628h | 1E1Ch | 1E1Ch | 1E1Eh | 1E1Eh | 1E20h | 1E20h | 1E22h | 1E22h |
0630h | 1E24h | 1E24h | 1E26h | 1E26h | 1E28h | 1E28h | 1E2Ah | 1E2Ah |
0638h | 1E2Ch | 1E2Ch | 1E2Eh | 1E2Eh | 1E30h | 1E30h | 1E32h | 1E32h |
0640h | 1E34h | 1E34h | 1E36h | 1E36h | 1E38h | 1E38h | 1E3Ah | 1E3Ah |
0648h | 1E3Ch | 1E3Ch | 1E3Eh | 1E3Eh | 1E40h | 1E40h | 1E42h | 1E42h |
0650h | 1E44h | 1E44h | 1E46h | 1E46h | 1E48h | 1E48h | 1E4Ah | 1E4Ah |
0658h | 1E4Ch | 1E4Ch | 1E4Eh | 1E4Eh | 1E50h | 1E50h | 1E52h | 1E52h |
0660h | 1E54h | 1E54h | 1E56h | 1E56h | 1E58h | 1E58h | 1E5Ah | 1E5Ah |
0668h | 1E5Ch | 1E5Ch | 1E5Eh | 1E5Eh | 1E60h | 1E60h | 1E62h | 1E62h |
0670h | 1E64h | 1E64h | 1E66h | 1E66h | 1E68h | 1E68h | 1E6Ah | 1E6Ah |
0678h | 1E6Ch | 1E6Ch | 1E6Eh | 1E6Eh | 1E70h | 1E70h | 1E72h | 1E72h |
0680h | 1E74h | 1E74h | 1E76h | 1E76h | 1E78h | 1E78h | 1E7Ah | 1E7Ah |
0688h | 1E7Ch | 1E7Ch | 1E7Eh | 1E7Eh | 1E80h | 1E80h | 1E82h | 1E82h |
0690h | 1E84h | 1E84h | 1E86h | 1E86h | 1E88h | 1E88h | 1E8Ah | 1E8Ah |
0698h | 1E8Ch | 1E8Ch | 1E8Eh | 1E8Eh | 1E90h | 1E90h | 1E92h | 1E92h |
06A0h | 1E94h | 1E94h | 1E96h | 1E97h | 1E98h | 1E99h | 1E9Ah | 1E9Bh |
06A8h | 1E9Ch | 1E9Dh | 1E9Eh | 1E9Fh | 1EA0h | 1EA0h | 1EA2h | 1EA2h |
06B0h | 1EA4h | 1EA4h | 1EA6h | 1EA6h | 1EA8h | 1EA8h | 1EAAh | 1EAAh |
06B8h | 1EACh | 1EACh | 1EAEh | 1EAEh | 1EB0h | 1EB0h | 1EB2h | 1EB2h |
06C0h | 1EB4h | 1EB4h | 1EB6h | 1EB6h | 1EB8h | 1EB8h | 1EBAh | 1EBAh |
06C8h | 1EBCh | 1EBCh | 1EBEh | 1EBEh | 1EC0h | 1EC0h | 1EC2h | 1EC2h |
06D0h | 1EC4h | 1EC4h | 1EC6h | 1EC6h | 1EC8h | 1EC8h | 1ECAh | 1ECAh |
06D8h | 1ECCh | 1ECCh | 1ECEh | 1ECEh | 1ED0h | 1ED0h | 1ED2h | 1ED2h |
06E0h | 1ED4h | 1ED4h | 1ED6h | 1ED6h | 1ED8h | 1ED8h | 1EDAh | 1EDAh |
06E8h | 1EDCh | 1EDCh | 1EDEh | 1EDEh | 1EE0h | 1EE0h | 1EE2h | 1EE2h |
06F0h | 1EE4h | 1EE4h | 1EE6h | 1EE6h | 1EE8h | 1EE8h | 1EEAh | 1EEAh |
06F8h | 1EECh | 1EECh | 1EEEh | 1EEEh | 1EF0h | 1EF0h | 1EF2h | 1EF2h |
0700h | 1EF4h | 1EF4h | 1EF6h | 1EF6h | 1EF8h | 1EF8h | 1EFAh | 1EFBh |
0708h | 1EFCh | 1EFDh | 1EFEh | 1EFFh | 1F08h | 1F09h | 1F0Ah | 1F0Bh |
0710h | 1F0Ch | 1F0Dh | 1F0Eh | 1F0Fh | 1F08h | 1F09h | 1F0Ah | 1F0Bh |
0718h | 1F0Ch | 1F0Dh | 1F0Eh | 1F0Fh | 1F18h | 1F19h | 1F1Ah | 1F1Bh |
0720h | 1F1Ch | 1F1Dh | 1F16h | 1F17h | 1F18h | 1F19h | 1F1Ah | 1F1Bh |
0728h | 1F1Ch | 1F1Dh | 1F1Eh | 1F1Fh | 1F28h | 1F29h | 1F2Ah | 1F2Bh |
0730h | 1F2Ch | 1F2Dh | 1F2Eh | 1F2Fh | 1F28h | 1F29h | 1F2Ah | 1F2Bh |
0738h | 1F2Ch | 1F2Dh | 1F2Eh | 1F2Fh | 1F38h | 1F39h | 1F3Ah | 1F3Bh |
0740h | 1F3Ch | 1F3Dh | 1F3Eh | 1F3Fh | 1F38h | 1F39h | 1F3Ah | 1F3Bh |
0748h | 1F3Ch | 1F3Dh | 1F3Eh | 1F3Fh | 1F48h | 1F49h | 1F4Ah | 1F4Bh |
0750h | 1F4Ch | 1F4Dh | 1F46h | 1F47h | 1F48h | 1F49h | 1F4Ah | 1F4Bh |
0758h | 1F4Ch | 1F4Dh | 1F4Eh | 1F4Fh | 1F50h | 1F59h | 1F52h | 1F5Bh |
0760h | 1F54h | 1F5Dh | 1F56h | 1F5Fh | 1F58h | 1F59h | 1F5Ah | 1F5Bh |
0768h | 1F5Ch | 1F5Dh | 1F5Eh | 1F5Fh | 1F68h | 1F69h | 1F6Ah | 1F6Bh |
0770h | 1F6Ch | 1F6Dh | 1F6Eh | 1F6Fh | 1F68h | 1F69h | 1F6Ah | 1F6Bh |
0778h | 1F6Ch | 1F6Dh | 1F6Eh | 1F6Fh | 1FBAh | 1FBBh | 1FC8h | 1FC9h |
0780h | 1FCAh | 1FCBh | 1FDAh | 1FDBh | 1FF8h | 1FF9h | 1FEAh | 1FEBh |
0788h | 1FFAh | 1FFBh | 1F7Eh | 1F7Fh | 1F88h | 1F89h | 1F8Ah | 1F8Bh |
0790h | 1F8Ch | 1F8Dh | 1F8Eh | 1F8Fh | 1F88h | 1F89h | 1F8Ah | 1F8Bh |
0798h | 1F8Ch | 1F8Dh | 1F8Eh | 1F8Fh | 1F98h | 1F99h | 1F9Ah | 1F9Bh |
07A0h | 1F9Ch | 1F9Dh | 1F9Eh | 1F9Fh | 1F98h | 1F99h | 1F9Ah | 1F9Bh |
07A8h | 1F9Ch | 1F9Dh | 1F9Eh | 1F9Fh | 1FA8h | 1FA9h | 1FAAh | 1FABh |
07B0h | 1FACh | 1FADh | 1FAEh | 1FAFh | 1FA8h | 1FA9h | 1FAAh | 1FABh |
07B8h | 1FACh | 1FADh | 1FAEh | 1FAFh | 1FB8h | 1FB9h | 1FB2h | 1FBCh |
07C0h | 1FB4h | 1FB5h | 1FB6h | 1FB7h | 1FB8h | 1FB9h | 1FBAh | 1FBBh |
07C8h | 1FBCh | 1FBDh | 1FBEh | 1FBFh | 1FC0h | 1FC1h | 1FC2h | 1FC3h |
07D0h | 1FC4h | 1FC5h | 1FC6h | 1FC7h | 1FC8h | 1FC9h | 1FCAh | 1FCBh |
07D8h | 1FC3h | 1FCDh | 1FCEh | 1FCFh | 1FD8h | 1FD9h | 1FD2h | 1FD3h |
07E0h | 1FD4h | 1FD5h | 1FD6h | 1FD7h | 1FD8h | 1FD9h | 1FDAh | 1FDBh |
07E8h | 1FDCh | 1FDDh | 1FDEh | 1FDFh | 1FE8h | 1FE9h | 1FE2h | 1FE3h |
07F0h | 1FE4h | 1FECh | 1FE6h | 1FE7h | 1FE8h | 1FE9h | 1FEAh | 1FEBh |
07F8h | 1FECh | 1FEDh | 1FEEh | 1FEFh | 1FF0h | 1FF1h | 1FF2h | 1FF3h |
0800h | 1FF4h | 1FF5h | 1FF6h | 1FF7h | 1FF8h | 1FF9h | 1FFAh | 1FFBh |
0808h | 1FF3h | 1FFDh | 1FFEh | 1FFFh | 2000h | 2001h | 2002h | 2003h |
0810h | 2004h | 2005h | 2006h | 2007h | 2008h | 2009h | 200Ah | 200Bh |
0818h | 200Ch | 200Dh | 200Eh | 200Fh | 2010h | 2011h | 2012h | 2013h |
0820h | 2014h | 2015h | 2016h | 2017h | 2018h | 2019h | 201Ah | 201Bh |
0828h | 201Ch | 201Dh | 201Eh | 201Fh | 2020h | 2021h | 2022h | 2023h |
0830h | 2024h | 2025h | 2026h | 2027h | 2028h | 2029h | 202Ah | 202Bh |
0838h | 202Ch | 202Dh | 202Eh | 202Fh | 2030h | 2031h | 2032h | 2033h |
0840h | 2034h | 2035h | 2036h | 2037h | 2038h | 2039h | 203Ah | 203Bh |
0848h | 203Ch | 203Dh | 203Eh | 203Fh | 2040h | 2041h | 2042h | 2043h |
0850h | 2044h | 2045h | 2046h | 2047h | 2048h | 2049h | 204Ah | 204Bh |
0858h | 204Ch | 204Dh | 204Eh | 204Fh | 2050h | 2051h | 2052h | 2053h |
0860h | 2054h | 2055h | 2056h | 2057h | 2058h | 2059h | 205Ah | 205Bh |
0868h | 205Ch | 205Dh | 205Eh | 205Fh | 2060h | 2061h | 2062h | 2063h |
0870h | 2064h | 2065h | 2066h | 2067h | 2068h | 2069h | 206Ah | 206Bh |
0878h | 206Ch | 206Dh | 206Eh | 206Fh | 2070h | 2071h | 2072h | 2073h |
0880h | 2074h | 2075h | 2076h | 2077h | 2078h | 2079h | 207Ah | 207Bh |
0888h | 207Ch | 207Dh | 207Eh | 207Fh | 2080h | 2081h | 2082h | 2083h |
0890h | 2084h | 2085h | 2086h | 2087h | 2088h | 2089h | 208Ah | 208Bh |
0898h | 208Ch | 208Dh | 208Eh | 208Fh | 2090h | 2091h | 2092h | 2093h |
08A0h | 2094h | 2095h | 2096h | 2097h | 2098h | 2099h | 209Ah | 209Bh |
08A8h | 209Ch | 209Dh | 209Eh | 209Fh | 20A0h | 20A1h | 20A2h | 20A3h |
08B0h | 20A4h | 20A5h | 20A6h | 20A7h | 20A8h | 20A9h | 20AAh | 20ABh |
08B8h | 20ACh | 20ADh | 20AEh | 20AFh | 20B0h | 20B1h | 20B2h | 20B3h |
08C0h | 20B4h | 20B5h | 20B6h | 20B7h | 20B8h | 20B9h | 20BAh | 20Bh |
08C8h | 20BCh | 20BDh | 20BEh | 20BFh | 20C0h | 20C1h | 20C2h | 20C3h |
08D0h | 20C4h | 20C5h | 20C6h | 20C7h | 20C8h | 20C9h | 20CAh | 20CBh |
08D8h | 20CCh | 20CDh | 20CEh | 20CFh | 20D0h | 20D1h | 20D2h | 20D3h |
08E0h | 20D4h | 20D5h | 20D6h | 20D7h | 20D8h | 20D9h | 20DAh | 20DBh |
08E8h | 20DCh | 20DDh | 20DEh | 20DFh | 20E0h | 20E1h | 20E2h | 20E3h |
08F0h | 20E4h | 20E5h | 20E6h | 20E7h | 20E8h | 20E9h | 20EAh | 20EBh |
08F8h | 20ECh | 20EDh | 20EEh | 20EFh | 20F0h | 20F1h | 20F2h | 20F3h |
0900h | 20F4h | 20F5h | 20F6h | 20F7h | 20F8h | 20F9h | 20FAh | 20FBh |
0908h | 20FCh | 20FDh | 20FEh | 20Fh | 2100h | 2101h | 2102h | 2103h |
0910h | 2104h | 2105h | 2106h | 2107h | 2108h | 2109h | 210Ah | 210Bh |
0918h | 210Ch | 210Dh | 210Eh | 210Fh | 2110h | 2111h | 2112h | 2113h |
0920h | 2114h | 2115h | 2116h | 2117h | 2118h | 2119h | 211Ah | 211Bh |
0928h | 211Ch | 211Dh | 211Eh | 211Fh | 2120h | 2121h | 2122h | 2123h |
0930h | 2124h | 2125h | 2126h | 2127h | 2128h | 2129h | 212Ah | 212Bh |
0938h | 212Ch | 212Dh | 212Eh | 212Fh | 2130h | 2131h | 2132h | 2133h |
0940h | 2134h | 2135h | 2136h | 2137h | 2138h | 2139h | 213Ah | 213Bh |
0948h | 213Ch | 213Dh | 213Eh | 213Fh | 2140h | 2141h | 2142h | 2143h |
0950h | 2144h | 2145h | 2146h | 2147h | 2148h | 2149h | 214Ah | 214Bh |
0958h | 214Ch | 214Dh | 2132h | 214Fh | 2150h | 2151h | 2152h | 2153h |
0960h | 2154h | 2155h | 2156h | 2157h | 2158h | 2159h | 215Ah | 215Bh |
0968h | 215Ch | 215Dh | 215Eh | 215Fh | 2160h | 2161h | 2162h | 2163h |
0970h | 2164h | 2165h | 2166h | 2167h | 2168h | 2169h | 216Ah | 216Bh |
0978h | 216Ch | 216Dh | 216Eh | 216Fh | 2160h | 2161h | 2162h | 2163h |
0980h | 2164h | 2165h | 2166h | 2167h | 2168h | 2169h | 216Ah | 216Bh |
0988h | 216Ch | 216Dh | 216Eh | 216Fh | 2180h | 2181h | 2182h | 2183h |
0990h | 2183h | FFFFh | 034Bh | 24B6h | 24B7h | 24B8h | 24B9h | 24BAh |
0998h | 24Bh | 24BCh | 24BDh | 24BEh | 24BFh | 24C0h | 24C1h | 24C2h |
09A0h | 24C3h | 24C4h | 24C5h | 24C6h | 24C7h | 24C8h | 24C9h | 24CAh |
09A8h | 24CBh | 24CCh | 24CDh | 24CEh | 24CFh | FFFFh | 0746h | 2C00h |
09B0h | 2C01h | 2C02h | 2C03h | 2C04h | 2C05h | 2C06h | 2C07h | 2C08h |
09B8h | 2C09h | 2C0Ah | 2C0Bh | 2C0Ch | 2C0Dh | 2C0Eh | 2C0Fh | 2C10h |
09C0h | 2C11h | 2C12h | 2C13h | 2C14h | 2C15h | 2C16h | 2C17h | 2C18h |
09C8h | 2C19h | 2C1Ah | 2C1Bh | 2C1Ch | 2C1Dh | 2C1Eh | 2C1Fh | 2C20h |
09D0h | 2C21h | 2C22h | 2C23h | 2C24h | 2C25h | 2C26h | 2C27h | 2C28h |
09D8h | 2C29h | 2C2Ah | 2C2Bh | 2C2Ch | 2C2Dh | 2C2Eh | 2C5Fh | 2C60h |
09E0h | 2C60h | 2C62h | 2C63h | 2C64h | 2C65h | 2C66h | 2C67h | 2C67h |
09E8h | 2C69h | 2C69h | 2C6Bh | 2C6Bh | 2C6Dh | 2C6Eh | 2C6Fh | 2C70h |
09F0h | 2C71h | 2C72h | 2C73h | 2C74h | 2C75h | 2C75h | 2C77h | 2C78h |
09F8h | 2C79h | 2C7Ah | 2C7Bh | 2C7Ch | 2C7Dh | 2C7Eh | 2C7Fh | 2C80h |
0A00h | 2C80h | 2C82h | 2C82h | 2C84h | 2C84h | 2C86h | 2C86h | 2C88h |
0A08h | 2C88h | 2C8Ah | 2C8Ah | 2C8Ch | 2C8Ch | 2C8Eh | 2C8Eh | 2C90h |
0A10h | 2C90h | 2C92h | 2C92h | 2C94h | 2C94h | 2C96h | 2C96h | 2C98h |
0A18h | 2C98h | 2C9Ah | 2C9Ah | 2C9Ch | 2C9Ch | 2C9Eh | 2C9Eh | 2CA0h |
0A20h | 2CA0h | 2CA2h | 2CA2h | 2CA4h | 2CA4h | 2CA6h | 2CA6h | 2CA8h |
0A28h | 2CA8h | 2CAAh | 2CAAh | 2CACh | 2CACh | 2CAEh | 2CAEh | 2CB0h |
0A30h | 2CB0h | 2CB2h | 2CB2h | 2CB4h | 2CB4h | 2CB6h | 2CB6h | 2CB8h |
0A38h | 2CB8h | 2CBAh | 2CBAh | 2CBCh | 2CBCh | 2CBEh | 2CBEh | 2CC0h |
0A40h | 2CC0h | 2CC2h | 2CC2h | 2CC4h | 2CC4h | 2CC6h | 2CC6h | 2CC8h |
0A48h | 2CC8h | 2CCAh | 2CCAh | 2CCCh | 2CCCh | 2CCEh | 2CCEh | 2CD0h |
0A50h | 2CD0h | 2CD2h | 2CD2h | 2CD4h | 2CD4h | 2CD6h | 2CD6h | 2CD8h |
0A58h | 2CD8h | 2CDAh | 2CDAh | 2CDCh | 2CDCh | 2CDEh | 2CDEh | 2CE0h |
0A60h | 2CE0h | 2CE2h | 2CE2h | 2CE4h | 2CE5h | 2CE6h | 2CE7h | 2CE8h |
0A68h | 2CE9h | 2CEAh | 2CEBh | 2CECh | 2CEDh | 2CEEh | 2CEFh | 2CF0h |
0A70h | 2CF1h | 2CF2h | 2CF3h | 2CF4h | 2CF5h | 2CF6h | 2CF7h | 2CF8h |
0A78h | 2CF9h | 2CFAh | 2CFBh | 2CFCh | 2CFDh | 2CFEh | 2CFFh | 10A0h |
0A80h | 10A1h | 10A2h | 10A3h | 10A4h | 10A5h | 10A6h | 10A7h | 10A8h |
0A88h | 10A9h | 10AAh | 10ABh | 10ACh | 10ADh | 10AEh | 10AFh | 10B0h |
0A90h | 10B1h | 10B2h | 10B3h | 10B4h | 10B5h | 10B6h | 10B7h | 10B8h |
0A98h | 10B9h | 10BAh | 10Bh | 10BCh | 10BDh | 10BEh | 10BFh | 10C0h |
0AA0h | 10C1h | 10C2h | 10C3h | 10C4h | 10C5h | FFFFh | D21Bh | FF21h |
0AA8h | FF22h | FF23h | FF24h | FF25h | FF26h | FF27h | FF28h | FF29h |
0AB0h | FF2Ah | FF2Bh | FF2Ch | FF2Dh | FF2Eh | FF2Fh | FF30h | FF31h |
0AB8h | FF32h | FF33h | FF34h | FF35h | FF36h | FF37h | FF38h | FF39h |
0AC0h | FF3Ah | FF5Bh | FF5Ch | FF5Dh | FF5Eh | FF5Fh | FF60h | FF61h |
0AC8h | FF62h | FF63h | FF64h | FF65h | FF66h | FF67h | FF68h | FF69h |
0AD0h | FF6Ah | FF6Bh | FF6Ch | FF6Dh | FF6Eh | FF6Fh | FF70h | FF71h |
0AD8h | FF72h | FF73h | FF74h | FF75h | FF76h | FF77h | FF78h | FF79h |
0AE0h | FF7Ah | FF7Bh | FF7Ch | FF7Dh | FF7Eh | FF7Fh | FF80h | FF81h |
0AE8h | FF82h | FF83h | FF84h | FF85h | FF86h | FF87h | FF88h | FF89h |
0AF0h | FF8Ah | FF8Bh | FF8Ch | FF8Dh | FF8Eh | FF8Fh | FF90h | FF91h |
0AF8h | FF92h | FF93h | FF94h | FF95h | FF96h | FF97h | FF98h | FF99h |
0B00h | FF9Ah | FF9Bh | FF9Ch | FF9Dh | FF9Eh | FF9Fh | FFA0h | FFA1h |
0B08h | FFA2h | FFA3h | FFA4h | FFA5h | FFA6h | FFA7h | FFA8h | FFA9h |
0B10h | FFAAh | FFABh | FFACh | FFADh | FFAEh | FFAFh | FFB0h | FFB1h |
0B18h | FFB2h | FFB3h | FFB4h | FFB5h | FFB6h | FFB7h | FFB8h | FFB9h |
0B20h | FFBAh | FFBBh | FFBCh | FFBDh | FFBEh | FFBFh | FFC0h | FFC1h |
0B28h | FFC2h | FFC3h | FFC4h | FFC5h | FFC6h | FFC7h | FFC8h | FFC9h |
0B30h | FFCAh | FFCBh | FFCCh | FFCDh | FFCEh | FFCFh | FFD0h | FFD1h |
0B38h | FFD2h | FFD3h | FFD4h | FFD5h | FFD6h | FFD7h | FFD8h | FFD9h |
0B40h | FFDAh | FFDBh | FFDCh | FFDDh | FFDEh | FFDFh | FFE0h | FFE1h |
0B48h | FFE2h | FFE3h | FFE4h | FFE5h | FFE6h | FFE7h | FFE8h | FFE9h |
0B50h | FFEAh | FFEBh | FFECh | FFEDh | FFEEh | FFEFh | FFF0h | FFF1h |
0B58h | FFF2h | FFF3h | FFF4h | FFF5h | FFF6h | FFF7h | FFF8h | FFF9h |
0B60h | FFFAh | FFFBh | FFFCh | FFFDh | FFFEh | FFFFh |
7.3 Entrée du répertoire de l’étiquette de volume
L’étiquette de volume est une chaîne Unicode qui permet aux utilisateurs finaux de distinguer leurs volumes de stockage. Dans le système de fichiers exFAT, l’étiquette de volume existe en tant qu’entrée de répertoire principal critique dans le répertoire racine (voir le tableau 26). Le nombre valide d’entrées de répertoire d’étiquettes de volume est compris entre 0 et 1.
Table 26 Volume Label DirectoryStructure
Nom du champ | Offset (octet) |
Taille (octet) |
Commentaires |
---|---|---|---|
EntryType | 0 | 1 | Ce champ est obligatoire et la section 7.3.1 définit son contenu. |
CharacterCount | 1 | 1 | Ce champ est obligatoire et la section 7.3.2 définit son contenu. |
VolumeLabel | 2 | 22 | Ce champ est obligatoire et la section 7.3.3 définit son contenu. |
Réservé | 24 | 8 | Ce champ est obligatoire et son contenu est réservé. |
7.3.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.3.1.1 TypeCode Field
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 Étiquette de volume, la valeur valide pour ce champ est 3.
7.3.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 de répertoire Étiquette de volume, la valeur valide pour ce champ est 0.
7.3.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.3.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.3.2 Champ CharacterCount
Le champ CharacterCount doit contenir la longueur de la chaîne Unicode que contient le champ VolumeLabel.
La plage de valeurs valide pour ce champ doit être :
Au moins 0, ce qui signifie que la chaîne Unicode a une longueur de 0 caractères (ce qui équivaut à l’absence d’étiquette de volume)
Au maximum 11, ce qui signifie que la chaîne Unicode est de 11 caractères
7.3.3 Champ VolumeLabel
Le champ VolumeLabel doit contenir une chaîne Unicode, qui est le nom convivial du volume. Le champ VolumeLabel comporte le même ensemble de caractères non valides que le champ FileName de l’entrée de répertoire File Name (voir section 7.7.3).
7.4 Entrée de répertoire de fichiers
Les entrées de répertoire de fichiers décrivent des fichiers et des répertoires. Il s’agit d’entrées de répertoire principal critiques et tout répertoire peut contenir zéro ou plusieurs entrées de répertoire de fichiers (voir le tableau 27). Pour qu’une entrée de répertoire de fichiers soit valide, une seule entrée de répertoire d’extension de flux et au moins une entrée de répertoire de nom de fichier doivent suivre immédiatement l’entrée répertoire de fichiers (voir respectivement section 7.6 et section 7.7).
Tableau 27 File DirectoryEntry
Nom du champ | Offset (octet) |
Taille (octet) |
Commentaires |
---|---|---|---|
EntryType | 0 | 1 | Ce champ est obligatoire et la section 7.4.1 définit son contenu. |
SecondaryCount | 1 | 1 | Ce champ est obligatoire et la section 7.4.2 définit son contenu. |
SetChecksum | 2 | 2 | Ce champ est obligatoire et la section 7.4.3 définit son contenu. |
FileAttributes | 4 | 2 | Ce champ est obligatoire et la section 7.4.4 définit son contenu. |
Reserved1 | 6 | 2 | Ce champ est obligatoire et son contenu est réservé. |
CreateTimestamp | 8 | 4 | Ce champ est obligatoire et la section 7.4.5 a> définit son contenu. |
LastModifiedTimestamp | 12 | 4 | Ce champ est obligatoire et la section 7.4.6 définit son contenu. |
LastAccessedTimestamp | 16 | 4 | Ce champ est obligatoire et la section 7.4.7 définit son contenu. |
Create10msIncrement | 20 | 1 | Ce champ est obligatoire et la section 7.4.5 a> définit son contenu. |
LastModified10msIncrement | 21 | 1 | Ce champ est obligatoire et la section 7.4.6 définit son contenu. |
CreateUtcOffset | 22 | 1 | Ce champ est obligatoire et la section 7.4.5 a> définit son contenu. |
LastModifiedUtcOffset | 23 | 1 | Ce champ est obligatoire et la section 7.4.6 définit son contenu. |
LastAccessedUtcOffset | 24 | 1 | Ce champ est obligatoire et la section 7.4.7 définit son contenu. |
Reserved2 | 25 | 7 | Ce champ est obligatoire et son contenu est réservé. |
7.4.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.4.1.1 TypeCode Field
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 de fichiers, la valeur valide pour ce champ est 5.
7.4.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 de fichiers, la valeur valide pour ce champ est 0.
7.4.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.4.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.4.2 Champ SecondaryCount
Le champ SecondaryCount doit être conforme à la définition fournie dans le modèle Generic Primary DirectoryEntry (voir section 6.3.2).
7.4.3 Champ SetChecksum
Le champ SetChecksum doit être conforme à la définition fournie dans le modèle Generic Primary DirectoryEntry (voir section 6.3.3).
7.4.4 Champ FileAttributes
Le champ FileAttributes contient des indicateurs (voir le tableau 28).
Table 28 FileAttributes Field Structure
Nom du champ | Offset (bit) |
Taille (bits) |
Commentaires |
---|---|---|---|
Lecture seule | 0 | 1 | Ce champ est obligatoire et conforme à la définition MS-DOS. |
Hidden | 1 | 1 | Ce champ est obligatoire et conforme à la définition MS-DOS. |
Système | 2 | 1 | Ce champ est obligatoire et conforme à la définition MS-DOS. |
Reserved1 | 3 | 1 | Ce champ est obligatoire et son contenu est réservé. |
Répertoire | 4 | 1 | Ce champ est obligatoire et conforme à la définition MS-DOS. |
Archive | 5 | 1 | Ce champ est obligatoire et conforme à la définition MS-DOS. |
Reserved2 | 6 | 10 | Ce champ est obligatoire et son contenu est réservé. |
7.4.5 Champs CreateTimestamp, Create10msIncrement et CreateUtcOffset
En combinaison, les champs CreateTimestamp et CreateTime10msIncrement décrivent la date et l’heure locales de création du fichier/répertoire donné. Le champ CreateUtcOffset décrit le décalage de la date et de l’heure locales par rapport à UTC. Les implémentations doivent définir ces champs lors de la création du jeu d’entrée de répertoire donné.
Ces champs doivent être conformes aux définitions des champs Timestamp, 10msIncrement et UtcOffset (voir section 7.4.8, section 7.4.9 et section 7.4.10, respectivement).
7.4.6 Champs LastModifiedTimestamp, LastModified10msIncrement et LastModifiedUtcOffset
En combinaison, les champs LastModifiedTimestamp et LastModifiedTime10msIncrement doivent décrire la date et l’heure locales de la dernière modification du contenu de l’un des clusters associés à l’entrée de répertoire d’extension stream donnée. Le champ LastModifiedUtcOffset décrit le décalage de la date et de l’heure locales par rapport à UTC. Les implémentations doivent mettre à jour ces champs :
Après avoir modifié le contenu de l’un des clusters associés à l’entrée de répertoire d’extension Stream donnée (à l’exception du contenu qui existe au-delà du point décrit par le champ ValidDataLength)
Lors de la modification des valeurs des champs ValidDataLength ou DataLength
Ces champs doivent être conformes aux définitions des champs Timestamp, 10msIncrement et UtcOffset (voir section 7.4.8, section 7.4.9 et section 7.4.10, respectivement).
7.4.7 Champs LastAccessedTimestamp et LastAccessedUtcOffset
Le champ LastAccessedTimestamp doit décrire la date et l’heure locales du dernier accès au contenu de l’un des clusters associés à l’entrée de répertoire Stream Extension donnée. Le champ LastAccessedUtcOffset décrit le décalage de la date et de l’heure locales par rapport à UTC. Les implémentations doivent mettre à jour ces champs :
Après avoir modifié le contenu de l’un des clusters associés à l’entrée de répertoire Stream Extension donnée (à l’exception des contenus qui existent au-delà de ValidDataLength)
Lors de la modification des valeurs des champs ValidDataLength ou DataLength
Les implémentations doivent mettre à jour ces champs après avoir lu le contenu de l’un des clusters associés à l’entrée de répertoire Stream Extension donnée.
Ces champs doivent être conformes aux définitions des champs Timestamp et UtcOffset (voir section 7.4.8 et section 7.4.10, respectivement).
7.4.8 Champs d’horodatage
Les champs d’horodatage décrivent à la fois la date et l’heure locales, jusqu’à une résolution de deux secondes (voir le tableau 29).
Table 29 Timestamp Field Structure
Nom du champ | Offset (bit) |
Taille (bits) |
Commentaires |
---|---|---|---|
DoubleSeconds | 0 | 5 | Ce champ est obligatoire et la section 7.4.8.1 définit son contenu. |
Minute | 5 | 6 | Ce champ est obligatoire et la section 7.4.8.2 définit son contenu. |
Heure | 11 | 5 | Ce champ est obligatoire et la section 7.4.8.3 définit son contenu. |
Jour | 16 | 5 | Ce champ est obligatoire et la section 7.4.8.4 définit son contenu. |
Month | 21 | 4 | Ce champ est obligatoire et la section 7.4.8.5 définit son contenu. |
Year | 25 | 7 | Ce champ est obligatoire et la section 7.4.8.6 définit son contenu. |
7.4.8.1 Champ DoubleSeconds
Le champ DoubleSeconds doit décrire la partie secondes du champ Timestamp, en multiples de deux secondes.
La plage de valeurs valide pour ce champ doit être :
0, qui représente 0 seconde
29, ce qui représente 58 secondes
7.4.8.2 Champ minute
Le champ Minute doit décrire la partie minutes du champ Timestamp.
La plage de valeurs valide pour ce champ doit être :
0, qui représente 0 minute
59, ce qui représente 59 minutes
Champ 7.4.8.3 Heure
Le champ Heure doit décrire la partie heures du champ Timestamp.
La plage de valeurs valide pour ce champ doit être :
0, qui représente 00:00 heures
23, qui représente 23:00 heures
Champ jour 7.4.8.4
Le champ Jour doit décrire la partie jour du champ Timestamp.
La plage de valeurs valide pour ce champ doit être :
1, qui est le premier jour du mois donné
Dernier jour du mois donné (le mois donné définit le nombre de jours valides)
Champ 7.4.8.5 Mois
Le champ Mois doit décrire la partie mois du champ Timestamp.
La plage de valeurs valide pour ce champ doit être :
Au moins 1, ce qui représente janvier
Au plus 12, ce qui représente décembre
Champ 7.4.8.6 Année
Le champ Year doit décrire la partie année du champ Timestamp par rapport à l’année 1980. Ce champ représente l’année 1980 avec la valeur 0 et l’année 2107 avec la valeur 127.
Toutes les valeurs possibles pour ce champ sont valides.
7.4.9 10msIncrement Fields
Les champs 10msIncrement doivent fournir une résolution de temps supplémentaire à leurs champs d’horodatage correspondants dans des multiples de dix millisecondes.
La plage de valeurs valide pour ces champs doit être :
Au moins 0, ce qui représente 0 milliseconde
Au maximum 199, ce qui représente 1990 millisecondes
7.4.10 Champs UtcOffset
Les champs UtcOffset (voir tableau 30) décrivent le décalage entre UTC et la date et l’heure locales de leurs champs Timestamp et 10msIncrement correspondants. Le décalage entre UTC et la date et l’heure locales inclut les effets des fuseaux horaires et d’autres ajustements date-heure, tels que l’heure d’été et les changements régionaux d’heure d’été.
Table 30 UtcOffset Field Structure
Nom du champ | Offset (bit) |
Taille (bits) |
Commentaires |
---|---|---|---|
OffsetFromUtc | 0 | 7 | Ce champ est obligatoire et la section 7.4.10.1définit son contenu. |
OffsetValid | 7 | 1 | Ce champ est obligatoire et la section 7.4.10.2 définit son contenu. |
7.4.10.1 OffsetFromUtc Field
Le champ OffsetFromUtc doit décrire le décalage à partir de l’utc de la date et de l’heure locales que contiennent les champs Timestamp et 10msIncrement associés. Ce champ décrit le décalage par rapport à UTC par intervalles de 15 minutes (voir le tableau 31).
Tableau 31 Signification des valeurs du champ OffsetFromUtc
Valeur | Équivalent décimal signé | Description |
---|---|---|
3Fh | 63 | La date et l’heure locales sont UTC + 15:45 |
3Eh | 62 | La date et l’heure locales sont UTC + 15:30 |
. . . |
. . . |
. . . |
01h | 1 | La date et l’heure locales sont UTC + 00:15 |
00h | 0 | La date et l’heure locales sont UTC |
7Fh | -1 | La date et l’heure locales sont UTC – 00:15 |
. . . |
. . . |
. . . |
41h | -63 | La date et l’heure locales sont UTC – 15:45 |
40h | -64 | La date et l’heure locales sont UTC – 16:00 |
Comme l’indique le tableau ci-dessus, toutes les valeurs possibles pour ce champ sont valides. Toutefois, les implémentations doivent uniquement enregistrer la valeur 00h pour ce champ dans les cas suivants :
La date et l’heure locales sont en fait identiques à utc, auquel cas la valeur du champ OffsetValid doit être 1
La date et l’heure locales ne sont pas connues, auquel cas la valeur du champ OffsetValid doit être 1 et les implémentations considèrent UTC comme date et heure locales
UTC n’est pas connu, auquel cas la valeur du champ OffsetValid doit être 0
Si le décalage de date et d’heure local par rapport à UTC n’est pas un multiple d’intervalles de 15 minutes, les implémentations enregistrent 00h dans le champ OffsetFromUtc et considèrent UTC comme une date et une heure locales.
7.4.10.2 Champ OffsetValid
Le champ OffsetValid doit indiquer si le contenu du champ OffsetFromUtc est valide ou non, comme suit :
0, ce qui signifie que le contenu du champ OffsetFromUtc n’est pas valide
et doit être 00h
1, ce qui signifie que le contenu du champ OffsetFromUtc est valide
Les implémentations doivent uniquement définir ce champ sur la valeur 0 lorsque UTC n’est pas disponible pour le calcul de la valeur du champ OffsetFromUtc. Si ce champ contient la valeur 0, les implémentations doivent traiter les champs Timestamp et 10msIncrement comme ayant le même décalage UTC que la date et l’heure locales actuelles.
7.5 Entrée du répertoire GUID de volume
L’entrée du répertoire GUID de volume contient un GUID qui permet aux implémentations de distinguer les volumes de manière unique et programmatique. Le GUID de volume existe en tant qu’entrée de répertoire principal sans gravité dans le répertoire racine (voir tableau 32). Le nombre valide d’entrées de répertoire GUID de volume est compris entre 0 et 1.
Tableau 32 Répertoire GUID de volumeEntry
Nom du champ | Offset (octet) |
Taille (octet) |
Commentaires |
---|---|---|---|
EntryType | 0 | 1 | Ce champ est obligatoire et la section 7.5.1 définit son contenu. |
SecondaryCount | 1 | 1 | Ce champ est obligatoire et la section 7.5.2 définit son contenu. |
SetChecksum | 2 | 2 | Ce champ est obligatoire et la section 7.5.3 définit son contenu. |
GénéralPrimaryFlags | 4 | 2 | Ce champ est obligatoire et la section 7.5.4 définit son contenu. |
VolumeGuid | 6 | 16 | Ce champ est obligatoire et la section 7.5.5 définit son contenu. |
Réservé | 22 | 10 | Ce champ est obligatoire et son contenu est réservé. |
7.5.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.5.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 GUID de volume, la valeur valide pour ce champ est 0.
7.5.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 GUID de volume, la valeur valide pour ce champ est 1.
7.5.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.5.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.5.2 Champ SecondaryCount
Le champ SecondaryCount doit être conforme à la définition fournie dans le modèle Generic Primary DirectoryEntry (voir section 6.3.2).
Pour l’entrée de répertoire GUID de volume, la valeur valide pour ce champ est 0.
7.5.3 Champ SetChecksum
Le champ SetChecksum doit être conforme à la définition fournie dans le modèle Generic Primary DirectoryEntry (voir section 6.3.3).
7.5.4 GeneralPrimaryFlags Field
Le champ GeneralPrimaryFlags doit être conforme à la définition fournie dans le modèle Generic Primary DirectoryEntry (voir section 6.3.4) et définit le contenu du champ CustomDefined à réserver.
7.5.4.1 Allocation FieldPossible
Le champ AllocationPossible doit être conforme à la définition fournie dans le modèle Generic Primary DirectoryEntry (voir section 6.3.4.1).
Pour l’entrée de répertoire GUID de volume, la valeur valide pour ce champ est 0.
7.5.4.2 Champ NoFatChain
Le champ NoFatChain doit être conforme à la définition fournie dans le modèle Generic Primary DirectoryEntry (voir section 6.3.4.2).
7.5.5 Champ VolumeGuid
Le champ VolumeGuid doit contenir un GUID qui identifie de manière unique le volume donné.
Toutes les valeurs possibles pour ce champ sont valides, à l’exception du GUID null, qui est {00000000-0000-0000-0000-000000000000}.
7.6 Entrée du répertoire d’extension stream
L’entrée de répertoire Stream Extension est une entrée de répertoire secondaire critique dans les jeux d’entrées de répertoires de fichiers (voir tableau 33). Le nombre valide d’entrées de répertoire d’extension Stream dans un jeu d’entrées de répertoire de fichiers est 1. En outre, cette entrée de répertoire n’est valide que si elle suit immédiatement l’entrée répertoire Fichier.
Tableau 33 Stream Extension DirectoryEntry
Nom du champ | Offset (octet) |
Taille (octet) |
Commentaires |
---|---|---|---|
EntryType | 0 | 1 | Ce champ est obligatoire et la section 7.6.1 définit son contenu. |
GeneralSecondaryFlags | 1 | 1 | Ce champ est obligatoire et la section 7.6.2 définit son contenu. |
Reserved1 | 2 | 1 | Ce champ est obligatoire et son contenu est réservé. |
NameLength | 3 | 1 | Ce champ est obligatoire et la section 7.6.3 définit son contenu. |
NameHash | 4 | 2 | Ce champ est obligatoire et la section 7.6.4 définit son contenu. |
Reserved2 | 6 | 2 | Ce champ est obligatoire et son contenu est réservé. |
ValidDataLength | 8 | 8 | Ce champ est obligatoire et la section 7.6.5 définit son contenu. |
Réservé3 | 16 | 4 | Ce champ est obligatoire et son contenu est réservé. |
FirstCluster | 20 | 4 | Ce champ est obligatoire et la section 7.6.6 définit son contenu. |
DataLength | 24 | 8 | Ce champ est obligatoire et la section 7.6.7 définit son contenu. |
7.6.1 Champ EntryType
Le champ EntryType doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.1).
7.6.1.1 Champ TypeCode
Le champ TypeCode doit être conforme à la définition fournie dans le modèle Répertoire secondaire générique (voir section 6.4.1.1).
Pour l’entrée de répertoire Stream Extension, la valeur valide pour ce champ est 0.
7.6.1.2 TypeImportance Field
Le champ TypeImportance doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.1.2).
Pour l’entrée de répertoire Stream Extension, la valeur valide pour ce champ est 0.
7.6.1.3 TypeCategory Field
Le champ TypeCategory doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.1.3).
7.6.1.4 Champ InUtilisation
Le champ InUse doit être conforme à la définition fournie dans le modèle Répertoire secondaire générique (voir section 6.4.1.4).
7.6.2 Champ GeneralSecondaryFlags
Le champ GeneralSecondaryFlags doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.2) et définit le contenu du champ CustomDefined à réserver.
7.6.2.1 Allocation FieldPossible
Le champ AllocationPossible doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir la section 6.4.2.1).
Pour l’entrée du répertoire Stream Extension, la valeur valide pour ce champ est 1.
7.6.2.2 Champ NoFatChain
Le champ NoFatChain doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.2.2).
7.6.3 Champ NameLength
Le champ NameLength doit contenir la longueur de la chaîne Unicode que contiennent collectivement les entrées de répertoire de nom de fichier suivantes (voir la section 7.7).
La plage de valeurs valide pour ce champ doit être :
Au moins 1, qui est le nom de fichier le plus court possible
Au maximum 255, qui est le nom de fichier le plus long possible
La valeur du champ NameLength affecte également le nombre d’entrées de répertoire de nom de fichier (voir la section 7.7).
7.6.4 Champ NameHash
Le champ NameHash doit contenir un hachage de 2 octets (voir la figure 4) du nom de fichier monté. Cela permet aux implémentations d’effectuer une comparaison rapide lors de la recherche d’un fichier par nom. Il est important de noter que NameHash fournit une vérification sûre d’une incompatibilité. Les implémentations doivent vérifier toutes les correspondances NameHash avec une comparaison du nom de fichier à la version up-cased.
Figure 4 NameHash Computation
UInt16 NameHash
(
WCHAR * FileName, // points to an in-memory copy of the up-cased file name
UCHAR NameLength
)
{
UCHAR * Buffer = (UCHAR *)FileName;
UInt16 NumberOfBytes = (UInt16)NameLength * 2;
UInt16 Hash = 0;
UInt16 Index;
for (Index = 0; Index < NumberOfBytes; Index++)
{
Hash = ((Hash&1) ? 0x8000 : 0) + (Hash>>1) + (UInt16)Buffer[Index];
}
return Hash;
}
7.6.5 Champ ValidDataLength
Le champ ValidDataLength doit décrire l’étendue de l’écriture des données utilisateur du flux de données. Les implémentations doivent mettre à jour ce champ au fur et à mesure qu’elles écrivent des données plus loin dans le flux de données. Sur le support de stockage, les données comprises entre la longueur des données valide et la longueur des données du flux de données ne sont pas définies. Les implémentations retournent des zéros pour les opérations de lecture au-delà de la longueur des données valide.
Si l’entrée de répertoire File correspondante décrit un répertoire, la seule valeur valide pour ce champ est égale à la valeur du champ DataLength. Dans le cas contraire, la plage de valeurs valides pour ce champ doit être :
Au moins 0, ce qui signifie qu’aucune donnée utilisateur n’a été écrite dans le flux de données
Au maximum DataLength, ce qui signifie que les données utilisateur ont été écrites sur toute la longueur du flux de données
7.6.6 Champ FirstCluster
Le champ FirstCluster doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.3).
Ce champ doit contenir l’index du premier cluster du flux de données, qui héberge les données utilisateur.
7.6.7 Champ DataLength
Le champ DataLength doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.4).
Si l’entrée de répertoire File correspondante décrit un répertoire, la valeur valide pour ce champ est la taille entière de l’allocation associée, en octets, qui peut être 0. En outre, pour les répertoires, la valeur maximale de ce champ est de 256 Mo.
7.7 Entrée de répertoire de nom de fichier
Les entrées de répertoire de nom de fichier sont des entrées de répertoire secondaires critiques dans les ensembles d’entrées de répertoires de fichiers (voir le tableau 34). Le nombre valide d’entrées de répertoire de nom de fichier dans un jeu d’entrées de répertoire de fichiers est NameLength/15, arrondi à l’entier le plus proche. En outre, les entrées de répertoire Nom de fichier ne sont valides que si elles suivent immédiatement l’entrée du répertoire Stream Extension en tant que série consécutive. Les entrées du répertoire Nom de fichier se combinent pour former le nom de fichier pour l’ensemble d’entrées de répertoire de fichiers.
Tous les enfants d’une entrée de répertoire donnée doivent avoir des ensembles d’entrées de répertoire de nom de fichier uniques. C’est-à-dire qu’il ne peut pas y avoir de noms de fichiers ou de répertoires en double après la casse up dans un répertoire.
Tableau 34 File Name DirectoryEntry
Nom du champ | Offset (octet) |
Taille (octet) |
Commentaires |
---|---|---|---|
EntryType | 0 | 1 | Ce champ est obligatoire et la section 7.7.1 définit son contenu. |
GeneralSecondaryFlags | 1 | 1 | Ce champ est obligatoire et la section 7.7.2 définit son contenu. |
FileName | 2 | 30 | Ce champ est obligatoire et la section 7.7.3 définit son contenu. |
7.7.1 Champ EntryType
Le champ EntryType doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.1).
7.7.1.1 Champ TypeCode
Le champ TypeCode doit être conforme à la définition fournie dans le modèle Répertoire secondaire générique (voir section 6.4.1.1).
Pour l’entrée de répertoire Nom de fichier, la valeur valide pour ce champ est 1.
7.7.1.2 Champ TypeImportance
Le champ TypeImportance doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.1.2).
Pour l’entrée de répertoire Nom de fichier, la valeur valide pour ce champ est 0.
7.7.1.3 TypeCategory Field
Le champ TypeCategory doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.1.3).
7.7.1.4 Champ InUtilisation
Le champ InUse doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.1.4).
7.7.2 GeneralSecondaryFlags Field
Le champ GeneralSecondaryFlags doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.2) et définit le contenu du champ CustomDefined à réserver.
7.7.2.1 Allocation FieldPossible
Le champ AllocationPossible doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.2.1).
Pour l’entrée de répertoire Stream Extension, la valeur valide pour ce champ est 0.
7.7.2.2 Champ NoFatChain
Le champ NoFatChain doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.2.2).
7.7.3 Champ FileName
Le champ FileName doit contenir une chaîne Unicode, qui est une partie du nom de fichier. Dans l’ordre dans lequel les entrées de répertoire de nom de fichier existent dans un jeu d’entrées de répertoire de fichiers, les champs FileName concatènent pour former le nom de fichier du jeu d’entrées de répertoire de fichiers. Étant donné la longueur du champ FileName, 15 caractères, et le nombre maximal d’entrées de répertoire de nom de fichier, 17, la longueur maximale du nom de fichier concaténé final est de 255.
Le nom de fichier concaténé a le même jeu de caractères non autorisés que d’autres systèmes de fichiers basés sur FAT (voir le tableau 35). Les implémentations doivent définir les caractères inutilisés des champs FileName sur la valeur 0000h.
Table 35 Caractères fileName non valides
Code caractère | Description | Code caractère | Description | Code caractère | Description |
---|---|---|---|---|---|
0000h | Code de contrôle | 0001h | Code de contrôle | 0002h | Code de contrôle |
0003h | Code de contrôle | 0004h | Code de contrôle | 0005h | Code de contrôle |
0006h | Code de contrôle | 0007h | Code de contrôle | 0008h | Code de contrôle |
0009h | Code de contrôle | 000Ah | Code de contrôle | 000Bh | Code de contrôle |
000Ch | Code de contrôle | 000Dh | Code de contrôle | 000Eh | Code de contrôle |
000Fh | Code de contrôle | 0010h | Code de contrôle | 0011h | Code de contrôle |
0012h | Code de contrôle | 0013h | Code de contrôle | 0014h | Code de contrôle |
0015h | Code de contrôle | 0016h | Code de contrôle | 0017h | Code de contrôle |
0018h | Code de contrôle | 0019h | Code de contrôle | 001Ah | Code de contrôle |
001Bh | Code de contrôle | 001Ch | Code de contrôle | 001Dh | Code de contrôle |
001Eh | Code de contrôle | 001Fh | Code de contrôle | 0022h | Guillemets |
002Ah | Astérisque | 002Fh | Barre oblique | 003Ah | Deux-points |
003Ch | Signe Inférieur à | 003Eh | Signe Supérieur à | 003Fh | Point d'interrogation |
005Ch | Barre oblique inverse | 007Ch | Barre verticale |
Les noms de fichiers « . » et « . » ont la signification spéciale de « ce répertoire » et de « répertoire contenant », respectivement. Les implémentations n’enregistrent aucun de ces noms de fichiers réservés dans le champ FileName. Toutefois, les implémentations peuvent générer ces deux noms de fichiers dans les listes de répertoires pour faire référence au répertoire répertorié et au répertoire conteneur.
Les implémentations peuvent souhaiter limiter les noms de fichiers et de répertoires uniquement au jeu de caractères ASCII. Dans ce cas, ils doivent limiter leur utilisation de caractères à la plage de caractères valides dans les 128 premières entrées Unicode. Ils doivent toujours stocker les noms de fichiers et de répertoires en Unicode sur le volume et traduire vers/depuis ASCII/Unicode lors de l’interaction avec l’utilisateur.
7.8 Entrée de répertoire de l’extension du fournisseur
L’entrée de répertoire Vendor Extension est une entrée de répertoire secondaire bénigne dans les jeux d’entrées de répertoires de fichiers (voir le tableau 36). Un jeu d’entrées de répertoire de fichiers peut contenir n’importe quel nombre d’entrées de répertoire Vendor Extension, jusqu’à la limite des entrées de répertoire secondaire, moins le nombre d’autres entrées de répertoire secondaire. En outre, les entrées de répertoire d’extension fournisseur sont valides uniquement si elles ne précèdent pas les entrées de répertoire d’extension de flux et de nom de fichier requises.
Les entrées d’annuaire d’extension de fournisseur permettent aux fournisseurs d’avoir des entrées de répertoire uniques et spécifiques au fournisseur dans des jeux d’entrées de répertoires de fichiers individuels via le champ VendorGuid (voir le tableau 36). Les entrées de répertoire uniques permettent efficacement aux fournisseurs d’étendre le système de fichiers exFAT. Les fournisseurs peuvent définir le contenu du champ VendorDefined (voir le tableau 36). Les implémentations de fournisseurs peuvent conserver le contenu du champ VendorDefined et peuvent fournir des fonctionnalités spécifiques au fournisseur.
Les implémentations qui ne reconnaissent pas le GUID d’une entrée de répertoire d’extension fournisseur doivent traiter l’entrée de répertoire de la même façon que toute autre entrée de répertoire secondaire non reconnue non reconnue (voir la section 8.2).
Tableau 36 Vendor Extension DirectoryEntry
Nom du champ | Offset (octet) |
Taille (octet) |
Commentaires |
---|---|---|---|
EntryType | 0 | 1 | Ce champ est obligatoire et la section 7.8.1 définit son contenu. |
GeneralSecondaryFlags | 1 | 1 | Ce champ est obligatoire et la section 7.8.2 définit son contenu. |
VendorGuid | 2 | 16 | Ce champ est obligatoire et la section 7.8.3 définit son contenu. |
VendorDefined | 18 | 14 | Ce champ est obligatoire et les fournisseurs peuvent définir son contenu. |
7.8.1 Champ EntryType
Le champ EntryType doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.1).
7.8.1.1 TypeCode Field
Le champ TypeCode doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.1.1).
Pour l’entrée de répertoire Vendor Extension, la valeur valide pour ce champ est 0.
7.8.1.2 Champ TypeImportance
Le champ TypeImportance doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.1.2).
Pour l’entrée de répertoire Vendor Extension, la valeur valide pour ce champ est 1.
7.8.1.3 TypeCategory Field
Le champ TypeCategory doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.1.3).
7.8.1.4 Champ InUtilisation
Le champ InUse doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.1.4).
7.8.2 GeneralSecondaryFlags Field
Le champ GeneralSecondaryFlags doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.2) et définit le contenu du champ CustomDefined à réserver.
7.8.2.1 Allocation FieldPossible
Le champ AllocationPossible doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.2.1).
Pour l’entrée de répertoire Vendor Extension, la valeur valide pour ce champ est 0.
7.8.2.2 Champ NoFatChain
Le champ NoFatChain doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.2.2).
7.8.3 Champ VendorGuid
Le champ VendorGuid doit contenir un GUID qui identifie de manière unique l’extension fournisseur donnée.
Toutes les valeurs possibles pour ce champ sont valides, à l’exception du GUID null, qui est {00000000-0000-0000-0000-000000000000}. Toutefois, les fournisseurs doivent utiliser un outil de génération de GUID, tel que GuidGen.exe, pour sélectionner un GUID lors de la définition de leurs extensions.
La valeur de ce champ détermine la structure propre au fournisseur du champ VendorDefined.
7.9 Entrée d’annuaire d’allocation de fournisseur
L’entrée de répertoire Allocation de fournisseurs est une entrée de répertoire secondaire bénigne dans les jeux d’entrées de répertoires de fichiers (voir le tableau 37). Un jeu d’entrées de répertoire de fichiers peut contenir n’importe quel nombre d’entrées de répertoire d’allocation de fournisseurs, jusqu’à la limite des entrées de répertoire secondaire, moins le nombre d’autres entrées de répertoire secondaire. En outre, les entrées de répertoire d’allocation de fournisseur sont valides uniquement si elles ne précèdent pas les entrées de répertoire d’extension de flux et de nom de fichier requises.
Les entrées d’annuaire d’allocation de fournisseurs permettent aux fournisseurs d’avoir des entrées d’annuaire uniques et spécifiques au fournisseur dans des jeux d’entrées de répertoires de fichiers individuels via le champ VendorGuid (voir le tableau 37). Les entrées de répertoire uniques permettent efficacement aux fournisseurs d’étendre le système de fichiers exFAT. Les fournisseurs peuvent définir le contenu des clusters associés, le cas échéant. Les implémentations de fournisseurs peuvent conserver le contenu des clusters associés, le cas échéant, et peuvent fournir des fonctionnalités spécifiques au fournisseur.
Les implémentations qui ne reconnaissent pas le GUID d’une entrée de répertoire d’allocation de fournisseurs doivent traiter l’entrée de répertoire de la même façon que toute autre entrée de répertoire secondaire non reconnue non reconnue (voir la section 8.2).
Tableau 37 Vendor Allocation DirectoryEntry
Nom du champ | Offset (octet) |
Taille (octet) |
Commentaires |
---|---|---|---|
EntryType | 0 | 1 | Ce champ est obligatoire et la section 7.9.1 définit son contenu. |
GeneralSecondaryFlags | 1 | 1 | Ce champ est obligatoire et la section 7.9.2 définit son contenu. |
VendorGuid | 2 | 16 | Ce champ est obligatoire et la section 7.9.3 définit son contenu. |
VendorDefined | 18 | 2 | Ce champ est obligatoire et les fournisseurs peuvent définir son contenu. |
FirstCluster | 20 | 4 | Ce champ est obligatoire et la section 7.9.4 définit son contenu. |
DataLength | 24 | 8 | Ce champ est obligatoire et la section 7.9.5 définit son contenu. |
7.9.1 Champ EntryType
Le champ EntryType doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.1).
7.9.1.1 Champ TypeCode
Le champ TypeCode doit être conforme à la définition fournie dans le modèle Répertoire secondaire générique (voir section 6.4.1.1).
Pour l’entrée du répertoire Allocation du fournisseur, la valeur valide pour ce champ est 1.
7.9.1.2 Champ TypeImportance
Le champ TypeImportance doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.1.2).
Pour l’entrée du répertoire Allocation du fournisseur, la valeur valide pour ce champ est 1.
7.9.1.3 TypeCategory Field
Le champ TypeCategory doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.1.3).
7.9.1.4 Champ InUtilisation
Le champ InUse doit être conforme à la définition fournie dans le modèle Répertoire secondaire générique (voir section 6.4.1.4).
7.9.2 Champ GeneralSecondaryFlags
Le champ GeneralSecondaryFlags doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.2) et définit le contenu du champ CustomDefined à réserver.
7.9.2.1 Allocation FieldPossible
Le champ AllocationPossible doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir la section 6.4.2.1).
Pour l’entrée du répertoire Allocation du fournisseur, la valeur valide pour ce champ est 1.
7.9.2.2 Champ NoFatChain
Le champ NoFatChain doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.2.2).
7.9.3 Champ VendorGuid
Le champ VendorGuid doit contenir un GUID qui identifie de manière unique l’allocation de fournisseur donnée.
Toutes les valeurs possibles pour ce champ sont valides, à l’exception du GUID null, qui est {00000000-0000-0000-0000-000000000000}. Toutefois, les fournisseurs doivent utiliser un outil de génération de GUID, tel que GuidGen.exe, pour sélectionner un GUID lors de la définition de leurs extensions.
La valeur de ce champ détermine la structure propre au fournisseur du contenu des clusters associés, le cas échéant.
7.9.4 Champ FirstCluster
Le champ FirstCluster doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.3).
7.9.5 Champ DataLength
Le champ DataLength doit être conforme à la définition fournie dans le modèle Generic Secondary DirectoryEntry (voir section 6.4.4).
7.10 Entrée du répertoire de remplissage TexFAT
Cette spécification, exFAT Revision 1.00 File System Basic Specification, ne définit pas l’entrée du répertoire TexFAT Padding. Toutefois, son code de type est 1 et son importance de type est 1. Les implémentations de cette spécification doivent traiter les entrées de répertoire TexFAT Padding de la même façon que toutes les autres entrées de répertoire principal non reconnues, les implémentations ne doivent pas déplacer les entrées de répertoire TexFAT Padding.
8 Notes d’implémentation
8.1 Ordre d’écriture recommandé
Les implémentations doivent garantir que le volume est aussi résilient que possible aux pannes d’alimentation et autres défaillances inévitables. Lors de la création d’entrées d’annuaire ou de la modification des allocations de cluster, les implémentations doivent généralement suivre cet ordre d’écriture :
Définissez la valeur du champ VolumeDirty sur 1
Mettre à jour le FAT actif, si nécessaire
Mettre à jour la bitmap d’allocation active
Créer ou mettre à jour l’entrée de répertoire, si nécessaire
Effacez la valeur du champ VolumeDirty sur 0, si sa valeur avant la première étape était 0
Lors de la suppression d’entrées d’annuaire ou de la libération des allocations de cluster, les implémentations doivent suivre cet ordre d’écriture :
Définissez la valeur du champ VolumeDirty sur 1
Supprimer ou mettre à jour l’entrée de répertoire, si nécessaire
Mettre à jour le FAT actif, si nécessaire
Mettre à jour la bitmap d’allocation active
Effacez la valeur du champ VolumeDirty sur 0, si sa valeur avant la première étape était 0
8.2 Implications des entrées de répertoire non reconnues
Les spécifications exFAT futures du même numéro de révision majeur, 1, et du même nombre de révisions mineures supérieur à 0, peuvent définir de nouvelles entrées d’annuaire principal, secondaire critique et secondaire bénin. Seules les spécifications exFAT d’un nombre de révision majeur supérieur peuvent définir de nouvelles entrées de répertoire principal critiques. Les implémentations de cette spécification, exFAT Revision 1.00 File System Basic Specification, doivent être en mesure de monter et d’accéder à n’importe quel volume exFAT de la révision principale numéro 1 et à tout numéro de révision mineur. Cela présente des scénarios dans lesquels une implémentation peut rencontrer des entrées de répertoire qu’elle ne reconnaît pas. Les éléments suivants décrivent les implications de ces scénarios :
La présence d’entrées de répertoire principal critiques non reconnues dans le répertoire racine rend le volume non valide. La présence de toute entrée de répertoire principal critique, à l’exception des entrées du répertoire Fichier, dans tout répertoire non racine, rend le répertoire d’hébergement non valide.
Les implémentations ne doivent pas modifier les entrées de répertoire principal non reconnues ou les allocations de cluster associées. Toutefois, lors de la suppression d’un répertoire et uniquement lors de la suppression d’un répertoire, les implémentations suppriment les entrées de répertoire principal bénignes non reconnues et libèrent toutes les allocations de cluster associées, le cas échéant.
Les implémentations ne doivent pas modifier les entrées de répertoires secondaires critiques non reconnues ou les allocations de cluster associées. La présence d’une ou de plusieurs entrées de répertoires secondaires critiques non reconnues dans un jeu d’entrées de répertoires rend l’ensemble du jeu d’entrées de répertoire non reconnu. Lors de la suppression d’un jeu d’entrées de répertoire qui contient une ou plusieurs entrées de répertoire secondaire critique non reconnues, les implémentations libèrent toutes les allocations de cluster, le cas échéant, associées à des entrées de répertoires secondaires critiques non reconnues. En outre, si le jeu d’entrées d’annuaire décrit un répertoire, les implémentations peuvent :
Parcourir le répertoire
Énumérer les entrées de répertoire qu’il contient
Supprimer des entrées de répertoires contenus
Déplacer les entrées de répertoire autonome vers un autre répertoire
Toutefois, les implémentations ne doivent pas :
Modifier les entrées de répertoires autonomes, à l’exception de la suppression, comme indiqué
Créer des entrées de répertoire autonome
Ouvrir les entrées de répertoire autonome, sauf parcourir et énumérer, comme indiqué
Les implémentations ne doivent pas modifier les entrées de répertoire secondaire non reconnues ou les allocations de cluster associées. Les implémentations doivent ignorer les entrées de répertoire secondaire bénignes non reconnues. Lors de la suppression d’un jeu d’entrées d’annuaire, les implémentations libèrent toutes les allocations de cluster, le cas échéant, associées à des entrées d’annuaire secondaires bénignes non reconnues.
9 Limites du système de fichiers
9.1 Limites de taille de secteur
Le champ BytesPerSectorShift définit les limites de taille de secteur inférieur et supérieur (qui évalue à la limite inférieure : 512 octets ; limite supérieure : 4 096 octets).
9.2 Limites de taille du cluster
Le champ SectorsPerClusterShift définit les limites de taille de cluster inférieure et supérieure (limite inférieure : 1 secteur ; limite supérieure : 25 -- Secteurs BytesPerSectorShift, qui s’évalue à 32 Mo).
9.3 Limites de taille du tas de cluster
Le tas de cluster doit contenir au moins suffisamment d’espace pour héberger les structures de système de fichiers de base suivantes : le répertoire racine, toutes les bitmaps d’allocation et la table de cas up.
La limite inférieure de taille du tas de cluster est une fonction de la limite de taille inférieure de chacune des structures de système de fichiers de base qui résident dans le tas de cluster. Même avec le plus petit cluster possible (512 octets), chacune des structures de système de fichiers de base n’a pas besoin de plus d’un cluster. Par conséquent, la limite inférieure est : 2 + clusters NumberOfFats, qui est évalué à 3 ou 4 clusters, en fonction de la valeur du champ NumberOfFats.
La limite supérieure de taille du tas de cluster est une fonction simple du nombre maximal possible de clusters, défini par le champ ClusterCount (limite supérieure : 232-11 clusters). Quelle que soit la taille du cluster, un tel tas de cluster dispose de suffisamment d’espace pour héberger au moins les structures de système de fichiers de base.
9.4 Limites de taille de volume
Le champ VolumeLength définit les limites de taille de volume inférieure et supérieure (limite inférieure : 220/2 secteursOctetsPerSectorShift, qui est évaluée à 1 Mo ; limite supérieure : 264-1 secteurs, ce qui, compte tenu de la plus grande taille de secteur possible, s’évalue à environ 64ZB). Toutefois, cette spécification recommande de ne pas dépasser 2clusters 24-2 dans le tas de cluster (voir la section 3.1.9). Par conséquent, la limite supérieure recommandée d’un volume est : ClusterHeapOffset + (224-2) * 2SectorsPerClusterShift. Étant donné la plus grande taille de cluster possible, 32 Mo, et en supposant que ClusterHeapOffset est de 96 Mo (suffisamment d’espace pour les régions de démarrage principal et de sauvegarde et uniquement pour la première fat), la limite supérieure recommandée d’un volume est d’environ 512 To.
9.5 Limites de taille de répertoire
Le champ DataLength de l’entrée de répertoire Stream Extension définit les limites de taille de répertoire inférieure et supérieure (limite inférieure : 0 octet ; limite supérieure : 256 Mo). Cela signifie qu’un répertoire peut héberger jusqu’à 8 388 608 entrées de répertoire (chaque entrée de répertoire consomme 32 octets). Étant donné le plus petit jeu d’entrées de répertoire de fichiers possible, trois entrées de répertoire, un répertoire peut héberger jusqu’à 2 796 202 fichiers.
10 Annexe
10.1 Identificateurs uniques globaux (GUID)
Un GUID est l’implémentation Microsoft d’un identificateur universel unique. Un GUID est une valeur de 128 bits composée d’un groupe de 8 chiffres hexadécimaux, suivi de trois groupes de 4 chiffres hexadécimaux chacun et d’un groupe de 12 chiffres hexadécimaux, par exemple {6B29FC40-CA47-1067-B31D-00DDD010662DA}, (voir le tableau 38).
Structure GUID du tableau 38
Nom du champ | Offset (octet) |
Taille (octets) |
Commentaires |
---|---|---|---|
Données1 | 0 | 4 | Ce champ est obligatoire et contient les quatre octets du premier groupe du GUID (6B29FC40h de l’exemple). |
Données2 | 4 | 2 | Ce champ est obligatoire et contient les deux octets du deuxième groupe du GUID (CA47h de l’exemple). |
Données3 | 6 | 2 | Ce champ est obligatoire et contient les deux octets du troisième groupe du GUID (1 067h de l’exemple). |
Data4[0] | 8 | 1 | Ce champ est obligatoire et contient l’octet le plus significatif du quatrième groupe du GUID (B3h de l’exemple). |
Data4[1] | 9 | 1 | Ce champ est obligatoire et contient l’octet le moins significatif du quatrième groupe du GUID (1Dh dans l’exemple). |
Data4[2] | 10 | 1 | Ce champ est obligatoire et contient le premier octet du cinquième groupe du GUID (00h de l’exemple). |
Data4[3] | 11 | 1 | Ce champ est obligatoire et contient le deuxième octet du cinquième groupe du GUID (DDh de l’exemple). |
Data4[4] | 12 | 1 | Ce champ est obligatoire et contient le troisième octet du cinquième groupe du GUID (01h de l’exemple). |
Data4[5] | 13 | 1 | Ce champ est obligatoire et contient le quatrième octet du cinquième groupe du GUID (06h de l’exemple). |
Data4[6] | 14 | 1 | Ce champ est obligatoire et contient le cinquième octet du cinquième groupe du GUID (62h de l’exemple). |
Data4[7] | 15 | 1 | Ce champ est obligatoire et contient le sixième octet du cinquième groupe du GUID (DAh de l’exemple). |
10.2 Tables de partition
Pour garantir l’interopérabilité des volumes exFAT dans un large ensemble de scénarios d’utilisation, les implémentations doivent utiliser le type de partition 07h pour le stockage partitionné MBR et le GUID de partition {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7} pour le stockage partitionné GPT.
11 Historique des modifications de la documentation
Le tableau 39 décrit l’historique des mises en production, des corrections apportées à, des ajouts à, des suppressions et des clarifications de ce document.
Tableau 39 Historique des modifications de la documentation
Date | Description de la modification |
---|---|
08-Jan-2008 | Première version de la spécification de base, qui comprend : Section 1, Introduction Section 2, Section 3, Régions de démarrage principales et de sauvegarde Section 4, Région de la table d’allocation de fichiers Section 5, Région de données Section 6, Structure de répertoires Section 7, Définitions d’entrée de répertoire Section 8, Notes d’implémentation Section 9, Limites du système de fichiers Section 10, Annexe |
08-Juin-2008 | Deuxième version de la spécification de base, qui inclut les modifications suivantes : Ajout de l’article 11, Ajout des entrées d’annuaire Vendor Extension et Vendor Allocation dans les sections 7.8 et 7.9 Ajout de la table de cas à la hausse recommandée dans les sections 7.2.5 et 7.2.5.1 Ajout des champs UtcOffset dans la section 7.4 et ajout de l’acronyme UTC dans section 1.3 Correction de la taille du champ CustomDefined dans le tableau 19 Correction de la plage valide de valeurs NameLength dans la section 7.6.3 Correction et clarification des champs Timestamp et 10msIncrement dans la section 7.4 Clarification de la structure paramètres Null dans la section 3.3 Clarification de la signification des valeurs du champ NoFatChain dans la section 6.3.4.2 Clarification de la signification des valeurs du champ DataLength dans la section 6.2.3 Clarification du champ VolumeDirty dans la section 3.1.13.2 et ordre d’écriture recommandé dans la section 8.1 Clarification du champ MediaFailure dans la section 3.1.13.3 |
01-Oct-2008 | Troisième version de la spécification de base, qui inclut les modifications suivantes : Ajout de SHALL, SHOULD et MAY aux explications sur le terrain Ajout de la définition UTC dans le tableau 2, section 1.3 Modification des sections 1.5 pour garantir l’alignement avec le document de spécification TexFAT. Clarification de la restriction selon laquelle seul Microsoft peut définir la disposition des entrées d’annuaire dans la section 6.2 Ajout d’une clarification indiquant que FirstCluster Field doit être égal à zéro si dataLength est égal à zéro et à NoFatChain à la section 6.3.5 et à la section 6.4.3 Exigences claires pour les entrées de répertoire de fichiers valides dans la section 7.4 Ajout de la condition requise pour les noms de fichiers et de répertoires uniques à la section 7.7 Ajout d’une note d’implémentation pour ASCII à la fin de la section 7.7.3 |
01-Jan-2009 | Quatrième version de la spécification de base, qui inclut les modifications suivantes : Suppression des références aux entrées Windows CE Access Control Ajout d’une clarification à la section 7.2.5.1 afin d’exiger explicitement une table de casse complète |
02-Sep-2009 | Cinquième version de la spécification de base, qui comprend les modifications suivantes : Modifications apportées à la mise en forme des documents pour permettre une meilleure conversion PDF |
24-Fév-2010 | Sixième version de la spécification de base, qui comprend les modifications suivantes : Instruction incorrecte modifiée : « FirstCluster Field doit être égal à zéro si dataLength est égal à zéro et NoFatChain est défini » dans les sections 6.3.5 et 6.4.3 sur « Si le bit NoFatChain est 1, FirstCluster doit pointer vers un cluster valide dans le tas de cluster » pour clarifier qu’il doit y avoir une allocation valide si le bit NoFatChain est défini. Ajout de « 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 » à la section 6.3.6 et à la section 6.4.4 pour clarifier qu’il doit y avoir une allocation valide si le bit NoFatChain est défini. Mise à jour de l’avis de copyright vers 2010 |
26-août-2019 | Septième version de la spécification de base, qui comprend les modifications suivantes : Conditions légales mises à jour relatives à la spécification, notamment : Suppression de l’avis confidentiel Microsoft Suppression de la section Contrat de licence de documentation technique Microsoft Corporation Mise à jour de l’avis de copyright vers 2019 |
Commentaires
Envoyer et afficher des commentaires pour