Complément d'informations sur la Root Directory

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 :

1. comment un nom de fichier 8+3 est 'mémorisé' dans une entrée. Cliquer ici
2. comment un nom de fichier LFN est 'mémorisé' dans une ou plusieurs entrées. Cliquer ici
3. le caractère E5. Cliquer ici

Remarques :

1. le mot 'fichier' employé ici est à prendre au sens large du terme. Ainsi, la création d'un sous-répertoire, sous la racine, entraîne la création de 2 entrées dans la root directory (Vous savez les fameux .et .. visibles quand vous listez le contenu d'un répertoire) au même titre qu'un fichier de données. Pour le SGF, tout est fichier.
2. quand un fichier est créé dans un sous-répertoire, l'entrée de ce fichier ne figure pas dans la root directory MAIS dans le cluster attribué au répertoire par le SGF. Donc, si vous visualisez les secteurs de ce cluster, vous verrez toutes les entrées concernant les données incluses dans ce répertoire. (Voilà pourquoi il est possible de créer une 'infinité' de fichiers dans un sous-répertoire alors que le nombre est limité sous la racine).

Le caractère E5h

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

Retour en haut de page

Entrée dans la root directory - fichier DOS 8 + 3

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 d'une entrée (DOS 8+3)

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.

Le nom du fichier

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

Retour - les 16 premiers octets

L'extension du fichier

En 08h, la zone de 3 octets contient l'extension du fichier en ASCII, ici : 545854h donne en clair 'TXT'.

Retour - les 16 premiers octets

Les attributs du fichier

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

Retour - les 16 premiers octets

Une zone réservée

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.

Retour - les 16 premiers octets

L'heure de modification

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 :

- 'redresser' les octets (ici, nous aurons 72 73h)
- appliquer le masque hhhhh mmmmmm sssss où h représente un bit pour le chiffre des heures, m un bit pour le chiffre des minutes et s un bit pour le chiffre des secondes
- multiplier le chiffre des secondes par 2. Car le masque des secondes étant sur 5 bits, l'intervalle représentable est [0-31].

La description de la codification utilisée pour l'heure est visible ici.

Retour - les 16 premiers octets

Les 16 derniers octets d'une entrée (DOS 8+3)

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.

La date de modification

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.

Retour - les 16 derniers octets

La date de dernier accès

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.

Retour - les 16 derniers octets

Zone réservée

En 14h, la zone de 2 octets est réservée. Ici, on a 0000h

Retour - les 16 derniers octets

L'heure de création

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 :

- 'redresser' les octets (ici, nous aurons 72 73h)
- appliquer le masque hhhhh mmmmmm sssss où h représente un bit pour le chiffre des heures, m un bit pour le chiffre des minutes et s un bit pour le chiffre des secondes
- multiplier le chiffre des secondes par 2. Car le masque des secondes étant sur 5 bits, l'intervalle représentable est [0-31].

La description de la codification utilisée pour l'heure est visible ici.

Retour - les 16 derniers octets

La date de création

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.

Retour - les 16 derniers octets

Le premier cluster occupé par le fichier

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.

Retour - les 16 derniers octets

La taille en octets

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

Retour - les 16 derniers octets

Retour en Haut de la page