Le système de gestion de fichier FAT (SGF) 'utilise' un répertoire principal (Root directory). Cette Root Directory s'étend sur plusieurs secteurs. Le nombre de secteurs occupé peut être calculé à partir de l'offset 11h du secteur de boot fat. Chaque fichier au format DOS 8+3 créé sous la racine possède une entrée dans la Root Directory. Les fichiers avec un nom de fichier long (Long File Name) peuvent occuper plusieurs entrées dans la Root Directory. Cette page a pour objectif de vous expliquer :
Remarques :
Quand un fichier est supprimé, il demeure toujours sur le disque. Le système de gestion FAT ne fait que le 'retirer' de la table d'index. Toutes les entrées de 32 octets dans le répertoire racine (si c'est un fichier du répertoire racine) concernant ce fichier sont modifiées et cela toujours de la même manière. Le premier des 32 octets de chaque entrée est initialisé avec la valeur E5h. Ainsi, quand le système de gestion de fichier 'lit' une entrée et qu'elle commence par E5h, alors il fait comme si l'entrée n'existait pas. Le fichier est 'invisible'. Il faut noter que la zone premier cluster de l'entrée (offsets 1Ah et 1Bh) n'est pas détruite. Par contre, l'entrée correspondante dans la table d'allocation de fichier est marquée comme libre. Cela signifie qu'il n'est plus possible de 'chaîner' les différents clusters occupés par le fichier supprimé.
Voici un extrait d'un des secteurs de la root directory :
Chaque entrée est sur 32 octets. Nous étudierons la deuxième entrée figurant dans le secteur ci-dessus (octets 20h - 3Fh). Cliquer sur l'un des rectangles pour connaître le rôle des octets figurant dans cette ligne. La numérotation sera relative par rapport au début des octets de l'entrée. Les octets auront donc une adresse relative allant de [ 00h à 1Fh ]
Les 16 premiers octets (ligne 1 de l'entrée) sont répartis en 5 zones matérialisées ci-dessus par des rectangles de couleurs. Cliquer sur le rectangle de votre choix pour obtenir les informations correspondantes.
En 00h, la zone de 8 octets contient le nom du fichier en ASCII, ici : 3049433031202020h donne en clair '01C01 '. Remarque : le 1 de droite est suivi de 3 caractères 'espace'.
En 08h, la zone de 3 octets contient l'extension du fichier en ASCII, ici : 545854h donne en clair 'TXT'.
En 0Bh, la zone d'un octet permet de connaître les attributs du fichier. La description des différentes valeurs utilisées est visible ici. Dans notre exemple, 20h signifie que seul l'attribut archive A est activé.
En 0Ch, la zone de 2 octets est réservée. En théorie, selon la norme 8+3, cette zone devrait être à 0000h. Mais, depuis l'utilisation des noms longs, cette zone varie, ici 18B9h. Je pense qu'elle 'indique' comment un nom DOS 8+3 apparait sous Explorer. Ainsi, sous Explorer si vous renommez un fichier 'court' en tapant, le nom entièrement en majuscule, il apparaitra en minuscule avec la première lettre en Majuscule. Cette manipulation entrainera une modification de cette zone réservée. Mais j'ignore les règles de la codification.
En 0Eh, la zone de 2 octets indique l'heure de modification. Dans notre exemple, 7372h signifie 14 heures 19 minutes et 38 secondes. Pour arriver à ce résultat, il faut :
La description de la codification utilisée pour l'heure est visible ici.
Les 16 derniers octets (ligne 2 de l'entrée) sont répartis en 7 zones. Cliquer sur le rectangle de votre choix pour obtenir les informations correspondantes.
En 10h, la zone de 2 octets contient la date de modification du fichier. Ici, nous avons 5926h .Il faut déjà 'redresser' les octets. Cela donne 2659h. Appliquons le convertion binaire. Appliquons le masque. Nous arrivons au 25 Février 1999. La description de la codification utilisée pour les dates est visible ici.
Pour voir une animation illustrant le décodage, cliquer ici.
En 12h, la zone de 2 octets indique la date de dernier accès. Ici, nous avons 6B26h .Il faut déjà 'redresser' les octets. Cela donne 266Bh. Appliquons le convertion binaire. Appliquons le masque. Nous arrivons au 11 Mars 1999. La description de la codification utilisée pour les dates est visible ici.
En 14h, la zone de 2 octets est réservée. Ici, on a 0000h
En 16h, la zone de 2 octets indique l'heure de création. Dans notre exemple, F871h signifie 14 heures 15 minutes et 48 secondes. Pour arriver à ce résultat, il faut :
La description de la codification utilisée pour l'heure est visible ici.
En 18h, la zone de 2 octets indique la date de création. Ici, nous avons 5926h .Il faut déjà 'redresser' les octets. Cela donne 2659h. Appliquons le convertion binaire. Appliquons le masque. Nous arrivons au 25 Février 1999. La description de la codification utilisée pour les dates est visible ici.
Pour voir une animation illustrant le décodage, cliquer ici.
En 1Ah, la zone de 2 octets correspond au numéro du premier cluster occupé par le fichier. Ici, 0200h devient 0002h soit 2 en base 10.
En 1Ch, la zone de 4 octets correspond à la taille du fichier en Octets. Ici, 25000000h devient 00000025h soit 37 en base 10. Le fichier fait donc 37 octets