Complément d'informations sur la FAT 12

Le système de gestion de fichier FAT utilise une table d'allocation de fichiers pour mémoriser la liste des clusters occupés par les fichiers.

Quand un fichier est créé sous la racine, les informations le concernant (nom, extension, date, taille etc..) sont mémorisées dans des espaces de 32 octets de la Root Directory. Parmi ces informations, figure le numéro du premier cluster attribué par le système de gestion de fichiers au fichier. Si le fichier a besoin de plus de clusters, le système d'exploitation les lui alloue. Il stocke le numéro des différents clusters attribués au fichier dans la Table d'Allocation des fichiers (File Allocation Table).

Selon la nature du support (disquette, petit disque dur, grand disque), le numéro de cluster est exprimé sur 12, 16 ou 32 bits.

Chaque cluster dispose d'une 'case' dans la table. Ainsi la case 3 est réservée pour le cluster 3, la case 17 est réservée pour le cluster 17.

Question : que contient la case 3 ? Elle peut contenir plusieurs valeurs :

 
FAT12
FAT16
une valeur indiquant que le cluster 3 est disponible
000
0000
une valeur indiquant que le cluster 3 est défectueux
FF7
FFF7
une valeur indiquant que le fichier qui occupe le cluster 3 se termine dans ce cluster 3
FF8 à FFF
FFF8 à FFFF
une valeur indiquant que le fichier occupant le cluster 3 continue dans un autre cluster. La valeur est alors égale au numéro du cluster qui contient la suite du fichier
003 à FF6
0003 à FFF6

La FAT12 pose un petit problème de déchiffrage, car la taille du mot mémoire est de 16 bits (soit 2 octets, 4 caractères hexadécimaux). Le numéro du cluster s'écrit sur 12 bits (soit 1 octet et demi, 3 caractères hexadécimaux). Si le quatrième caractère était mis systématiquement à 0, de la place serait perdue. Dans un souci d'optimisation, 2 entrées successives se combinent (2 x 12 bits = 24 bits soit 3 octets)

Exemple :

Soit une disquette formatée et contenant un seul fichier. Ce fichier de 2000 octets occupe les clusters 2, 3, 4 et 5.

Adresses Hexa
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
0000 0000
F0
FF
FF
03
40
00
05
F0
FF
00
00
00
00
00
00
00
Entrées imbriquées
0 et 1
2 et 3
4 et 5
6 et 7
8 et 9
  

Comment déchiffer tout cela, il faudrait avoir

une Idée de Programme.

Il faut trouver les octets de la FAT qui correspondent à l'entrée cherchée. Pour cela, il faut différentier les entrées de numéro pair et les entrées de numéro impair. Appliquer l'algorithme suivant :

SI entrée_paire ALORS

Numéro_Octet1_ALire <-- (N° entrée * 3) /2

Numéro_Octet2_ALire <-- (Numéro_Octet1_ALire + 1)

Inverser les 2 octets //* technologie Intel poids faible chargé en premier *//

Supprimer le caractère hexa décimal de gauche

Traduire en Décimal

SINON

Numéro_Octet1_ALire <-- PartieEntière[(N° entrée *3)/2]

Numéro_Octet2_ALire <-- (Numéro_Octet1_ALire + 1)

Inverser les 2 octets //* technologie Intel poids faible chargé en premier *//

Supprimer le caractère hexa décimal de droite

Traduire en décimal

FINSI

Si nous examinons l'algorithme, nous constatons que la seule difficulté est de 'savoir' si le caractère hexadécimal à retirer est le caractère de gauche ou le caractère de droite. Dans l'introduction, j'ai parlé d'une idée de programme, cela n'est pas par hasard.

Questions :

Comment écrit-on programme en abrégé ?

Réponse : Pg

Comment écrit-on 'phonétiquement' le mot Idée

Réponse : I D

Donc 'Idée de Programme' donne 'ID PG'

Et alors me direz-vous ?

Dans l'algo, nous avons vu que pour les entrées Impaires, il fallait enlever le caractère de Droite

et que pour les entrées Paires, il fallait enlever le caractère de Gauche

En résumé : Idée de Programme ===> I D .. P G ====> Impaire Droite ..... Paire Gauche

Appliquons cela à notre exemple et nous arrivons au tableau ci-dessous :

Remarques : il ne faut pas oublier que les numérotations des octets, des clusters, des secteurs commencent à 0. Pour les clusters, les entrées 0 et 1 sont réservées. Le premier fichier commence donc dans le cluster 2. Pour vérifier le chainage avec un éditeur hexadécimal, il faut