Les étapes

Étape 1 : préparation de la disquette

Il faut une disquette 1440 Ko. Cette disquette doit être formatée complétement (donc pas un formatage rapide). Ensuite, il faut vérifier que la disquette ne présente pas de secteurs défectueux via la commande chkdsk/f.

Formatage complet | Vérification de la qualité de la disquette

Étape 2 : le secteur de Boot

Lancer Hexworkshop. Menu Disk, sélectionner le lecteur A. Le premier secteur est visible. Le numéro est affiché dans la barre des titres 0/2879. La disquette contient 2880 secteurs [0;2879] de 512 octets.

Cela fait donc une capacité de 1440 Ko (2880 * 512 /1024)

Le secteur 0 est le secteur de boot de la disquette. Il contient des informations précises sur la structure de la disquette comme le type de formatage, le nom de la disquette (bien que ...), le nombre de secteur dans la FAT1, la FAT2, le nombre d'entrées dans le répertoire racine....

Dump du secteur 0 de la disquette

Pour connaître le rôle des octets du secteur de boot et les expliquations concernant le secteur de l'illustration, cliquer ici. Il est à noter que les 2 derniers octets (55AA) sont le code signature, le nombre magique que l'on retrouve dans nombre de secteurs importants (MBR, EBR, Boot ...)

Étape 3 : la cartographie

Quelles sont les conséquences de ce formatage. Il a divisé la disquette en plusieurs zones selon la cartographie suivante :

Cartographie d'une disquette 1440 Ko

Un fichier créé sur la disquette se verra attribué un (ou plusieurs) espace disque appelé cluster. Pour une disquette, un cluster se compose d'1 secteur. Il faut savoir que le numéro du cluster s'exprime sur 12 bits. Voilà pourquoi on parle de FAT12. Les numéros 0 et 1 sont réservés au système d'exploitation. Donc le premier cluster attribuable aux données de l'utilisateur est le cluster numéro 2. Pour connaître les clusters occupés par un fichier, il faut connaître le numéro de son premier cluster. Cette information peut être trouvée dans les octets du repértoire racine si le fichier est à la racine de la disquette. Si le fichier est stocké dans un répertoire, l'information peut être trouvée dans le (ou les) secteur attribué à ce répertoire. Muni de cette information, il faut parcourir les secteurs de la FAT pour connaitre le numéro du cluster suivant .... Cela est illustré d'une manière simplifiée dans un gif animé ici (un fichier New-07.txt occupe les clusters 2, 226, 227, 228 et 229).

Questions diverses :

1. combien de cluster peut-on définir sur 12 bits ?
2. pourquoi l'espace attribué à la FAT (File Allocation Table) est-il de 9 secteurs ?
3. pourquoi l'espace attribué à la Root Directory est-il de 14 secteurs ?

Réponses :

1. Sur 12 bits, le nombre de combinaisons possibles est égal à 2 puissance 12. Soit 4096. Sachant que les combinaisons 0 et 1 sont réservés, il reste 4094 combinaisons [2-4095]. Mais une disquette ne contient pas autant de clusters alors pourquoi ne pas avoir choisi une taille inférieure à 12 bits ?

   Regardons. Si le numéro est exprimé sur 11 bits, cela ferait un nombre de combinaisons réduit de moitié (2048) et maintenant nous serions dans le cas inverse. La taille du mot serait trop petite. Donc 12 bits est une bonne taille

2. Dans la FAT, il faut mémoriser des numéros de cluster. Un numéro s'écrit sur 12 bits soit 1,5 octets. Si nous partons du principe que nous avons au maximum 2879 secteurs (le secteur 0 étant déjà occupé). Il nous faut une table capable de sauvegarder 2879 informations. En nombre de secteurs, cela fait 9 secteurs (2879 *1.5 /512 = 8,4345703125). Là encore on peut se demander pourquoi ne pas prendre 8 secteurs puisque si 9 secteurs sont pour la FAT et 1 pour le boot, il reste à disposition 2870 secteurs. Si nous attribuons 8 secteurs à la FAT, cela permettrait la mémorisation de 2730 mots de 12 bits (512 * 8 / 1.5). L'espace serait trop petit. Donc 9 secteurs pour la FAT est une bonne taille.

3. Les informations à mémoriser sont le nom (8 caractères .. les contraintes du bon vieux DOS), l'extension (3 caractères), la date de création ... soient 32 octets. Le secteur de boot indique que la Root Directory peut contenir 224 entrées. Donc cela fait 14 secteurs (224 * 32 /512). Pourquoi ce nombre de 224 ? je l'ignore. Dans un secteur, il est possible de méoriser les informations de 16 fichiers à la norme DOS 8+3 (512/32). Si l'espace Root Directory s'agrandit, l'espace Data se restreint. Pourquoi un "quilibre" à 14 secteurs ? .... Si vous connaissez la raison, ou si vous avez un début d'explication ....

Étape 4 : Initialisation

Sous hexworkshop, il est possible de voir les deux entrées réservées dans le premier secteur de la FAT 1. Les autres entrées sont initialisées à 000. Le premier secteur de la FAT 2 (secteur 10) est identique. Les secteurs de la RootDirectory sont vierges (secteurs 19 à 32), la partie Data a été initialisée avec F6 (secteurs 33 à 2879).

Initialisation suite au formatage complet

Étape 5 : le label

Ouvrir une fenêtre DOS, et tapons la commande label a:RECUP. La disquette dispose donc maintenant d'un nom. Dans le secteur de boot (secteur 0 de la disquette), il y a une zone de 11 octets à l'adresse 0x2B pour mémoriser le nom du volume. Pendant l'opération de formatage, la zone contenait "NO NAME ".

Question : que contient-elle maintenant ?

Réponse : A priori, nous pourrions répondre "RECUP ". Eh bien, c'est raté. La zone dans le secteur de Boot contient toujours "NO NAME ".

Question : mais où est donc mémorisé "RECUP " ?

Réponse : une recherche avec HexWorkShop nous permet de découvrir l'information dans le secteur 19. L'attribution d'un nom entraine l'écriture d'une entrée de 32 octets comme pour la création d'un fichier (ou celle d'un répertoire).

Une entrée de 32 octets décrit le nom de volume de la disquette

Les 32 octets sont découpables en zones. Chacune ayant un rôle bien précis. Pour l'entrée ci-dessus, le décodage peut être lu ici.

Commentaire : les manipulations ont été effectuées sous W2k PRO. Sous NT4 le résultat est le même Le changement de nom via bouton droit/propriétés change bien le nom dans l'entrée mais pas dans la zone du secteur de Boot. Par contre sous Windows Me, la mise à jour a lieu au deux places. Voilà pourquoi nous sommes dans le côté Laboratoire.

Remarque : si nous examinons la FAT 1, nous n'observerons pas de changement. L'attribution d'un label, malgré qu'une entrée soit générée dans la Root directory, n'est pas perçu comme un fichier ou comme un répertoire. Ceci est logique puisqu'il n'y a pas attribution d'espace disque.

Étape 6 : la création de répertoires

Créer deux répertoires sous la racine de la disquette dans une fenêtre DOS via la commande md. L'un des répertoires sera nommé Nomcour t et le second NomLong. Attention, respecter la casse des caratères.

Création de répertoires dans une fenêtre de commande

Étape 7 : modifications liées aux répertoires

Quels doivent être les effets visibles de ces créations ? Normalement, deux entrées doivent être créées dans la Root Directory. Un espace disque minimal doit être attribué à chaque répertoire. C'est à dire 1 cluster pour chacun. Par voie de conséquences, la FAT a du subir des modifications. Vérifions tout cela avec HexWorkShop.

Premièrement, dans la Root Directory

Entrées dans la Root Directory correspondant à la création des 2 répertoires

Commentaires : nous n'avons pas 2 entrées comme prévu mais 4. Pourquoi ? Les noms de répertoire choisis (Nomcourt et NomLong) bien qu'ils ne dépassent pas 8 lettres ne respectent pas la norme DOS 8+3 car certains caractères sont en minuscules. Aussi le SGF a créé une entrée pour chacun à la norme DOS et une entrée LFN pour conserver la casse des caractères.

Deuxièmement, au niveau de la Root Directory

Commençons par le répertoire "Nomcourt"

> Il y a une entrée DOS 8+3 de 32 octets en ligne 0x040 et 0x050. Pour voir le décodage de l'entrée, cliquer ici

> Il y a une entrée LFN (Long File Name) en ligne 0x020 et 0x030. Pour voir le décodage de l'entrée, cliquer ici.

Poursuivons par le répertoire "NomLong"

> Il y a une entrée DOS 8+3 de 32 octets en ligne 0x080 et 0x090. Pour voir le décodage de l'entrée, cliquer ici

> Il y a une entrée LFN (Long File Name) en ligne 0x060 et 0x070. Pour voir le décodage de l'entrée, cliquer ici.

Au niveau de l'espace "Data"

> Le répertoire Nomcourt se voit attribuer le premier secteur physique de l'espace Data. Il s'agit du secteur N° 33. Cela correspond aussi au cluster N° 2. Quand, on liste le contenu d'un répertoire vide, le S.E. nous dit qu'il contient 2 fichiers : 'un fichier' . et 'un fichier' .. Un regard sur le secteur N° 33 nous montre qu'il y a création des 2 entrées dans ce secteur.

> Les 'fichiers' . et .. du répertoire Nomcourt

> Commentaire : nous pouvons noter que le numéro du premier cluster attribué au répertoire Nomcourt (ici cluster N° 2) est une information mémorisée à deux endroits. Une première fois dans les 32 octets qui décrivent Nomcourt au niveau de la root directory et une seconde fois dans les 32 premiers octets du premier cluster alloué.

> Le répertoire NomLong se voit aussi attribuer un cluster (Cluster N°4) qui correspond au secteur physique N°34.

> Les 'fichiers' . et .. du répertoire NomLong

> Le cluster attribué au répertoire Nomcourt (idem pour NomLong) jouera le même rôle qu'un des secteurs affectés au répertoire racine. Il servira à mémoriser par bloc de 32 octets les informations concernant les objets (fichiers, répertoires) que l'utilisateur créera dans Nomcourt.

> Commentaire : Un cluster (sur une disquette) contient 512 octets (1 secteur). Une entrée descriptive est un bloc de 32 entrées. Donc dans un cluster, il sera possible de mémoriser les informations d'un petit nombre d'objets.

> Question : Que va-t-il se passer quand le nombre d'objets sera important ?

Étape 8 : création de fichiers dans un répertoire

> Nous allons créer 50 fichiers dans le répertoire Nomcourt. Pour cela nous pouvons utiliser dfCreaFic. Les fichiers seront nommés COU-001.TXT, COU-002.TXT, COU-003.TXT .....COU-050.TXT.

> Attention, les fichiers devront avoir un nom à la norme DOS 8+3, une taille de 10 Ko. dfCreaFic vous affiche une boîte de dialogue avant la création, vérifiez bien que vos choix correspondent bien à l'objectif cherché. En particulier, faîtes bien attention à la casse des caractères.

> | Vérifier bien avant la création et après

Étape 9 : chaînage dans la FAT

> La création de ces 50 fichiers a entraîné beaucoup de modifications sur notre disquette. Déjà, chaque fichier faisant 10 Ko, il a besoin de 20 secteurs. Donc dans la fat (FAT 1 et FAT 2), le chaînage des clusters a été mémorisé. Nous pouvons voir que les secteurs 1, 2 et 3 sont 'touchés'.

> Si nous regardons par curiosité les secteurs 10, 11 et 12 (Fat 2). Ils sont similaires puisqu'ils servent de backup (enfin cela reste à prouver ... ).

> Les fichiers ayant été créés dans le répertoire Nomcourt, cela n'a eu aucune influence au niveau de la Root Directory. Il suffit de regarder le secteur 19 pour voir qu'il n'a pas changé.

> Les entrées de 32 octets décrivant les 50 fichiers sont dans les clusters affectés au répertoire Nomcourt. Nous connaissons le N° du premier cluster, c'est le numéro 2 ( = secteur N°33 ). Mais comme il y a 50 fichiers, il nous faut 4 clusters ( 50 * 32 / 512 = 3.125).

> Pour connaître les numéros de ces clusters, il faut calculer le chaînage en décodant la FAT 12 sachant que le premier cluster est le N° 2. La démarche de décodage est rappellé dans la partie compléments.

> Dans la boîte à outils, il y a dfFat12. Pour cela, sauvegardons le secteur de la FAT 1 via la commande export (menu File / Export ...) sous le nom recup020-sect0001.txt.. Puis, il faut charger le fichier dump sous dfFat12 en indiquant qu'il s'agit du secteur 1 de la FAT. Idem pour les secteurs 2 et 3. Indiquons que nous voulons faire le parcours pour le cluster N° 2 et nous obtenons la liste des clusters attribués (ainsi que les numéros des secteurs physiques correspondants).

> Liste chaînée des clusters alloués

> Donc, maintenant si nous regardons les secteurs 33, 315, 636 et 957 ( = clusters 2, 284, 605 et 926), nous aurons les descriptions (par bloc de 32 octets) de nos 50 fichiers.

> Les dumps complets peuvent être visualisés en cliquant sur chaque barre de titre (Drive A: ...) de l'image. Chacune des entrées de ces secteurs peut être décodée avec dfRootFat. Ainsi, appliquer à l'entrée de COU-001.TXT, le résultat sera celui-ci.

Étape 10 : l'utilisation de nom de fichier long

> Créons un fichier de 900 Ko dans le répertoire NomLong. Ce fichier s'appelle NLong900Ko-001.TXT. Attention, il ne faut pas se tromper dans le nom, la taille et l'emplacement.

> Regardons les entrées (blocs de 32 octets) créés. Nous savons qu'il y en a une pour le nom DOS 8+3. Pour le nom long (LFN), dans 32 octets, il y a mémorisation au maximum de 13 caractères du nom. Donc il nous faut 2 entrées LFN, le nom comportant 18 caractères (NLong900Ko-001.TXT). Le point situé entre le nom et l'extension est comptabilisé car en mode LFN, certains caractères interdits sous DOS 8+3 sont maintenant autorisés. Le fichier étant créé dans le répertoire NomLong, ces entrées sont stockées dans le premier cluster alloué au répertoire NomLong. Ici c'est dans le cluster N° 3 (secteur N° 34). Un regard avec hexworkshop nous confirme cela.

> Entrée LFN et entrée DOS 8+3

> Commentaires : ici, le nom court généré comporte un tilde ~ en 7 ième position. Le Système d'exploitation est Win2K. La gestion des noms courts générés n'est pas la même selon les S.E (Win9x, NT4, Win2K). L'entrée "nom court" est facilement identifiable car chaque caractère du nom est en majuscule et occupe 1 seul octet (table ASCII). L'entrée (ou les entrées) LFN est empilée au dessus de l'entrée "nom court". Chaque caractère du nom long est écrit sur 2octets (table Unicode). Pour voir le résultat du décodage des entrées, cliquer sur les rectangles de l'image, pour voir le dump complet du secteur 34, cliquer sur la barre des titres de l'image.

Étape 11 : suppression de fichier

> Supprimons le fichier COU-001.TXT. Trop tard.

> Question : Quelles sont les modifications engendrées par la suppression ?

> Réponse : Le nom du fichier est marqué "EFFACÉ" dans le bloc de 32 octets qui le décrit. Ce marquage consiste à remplacer le premier octet de chaque bloc de 32 octets le concernant par le code E5. Il faut donc dans un premier temps retrouver les entrées le décrivant. La fonction recherche de l'éditeur hexadécimal nous permet de retrouver le secteur. Recherchons "OU-001". Attention, l'éditeur peut trouver plusieurs secteurs contenant cette chaine. Mais connaissant la structure d'un bloc de 32 octets pour les noms courts, cela ne devrait pas poser de problème.

> Commentaires : la recherche est plus délicate quand il faut chercher un nom long (Code Unicode) et bien souvent il n'est pas facile de connaître le nom court généré. Il faut être patient et prudent.

> Une chose est très interessante, nous pouvons constater que seul le premier octet est modifié. La zone qui contient le numéro du premier cluster est toujours renseigné. Cela permet de savoir à partir de quel endroit il faudra refaire le chaînage dans la FAT. De même la zone indiquant la taille a conservé sa valeur initiale. Cela permet de calculer combien de secteurs étaient alloués au fichier avant la suppression.

> Question : si nous remplaçons E5 par une autre valeur ? que va-t-il se passer ?

> Réponse en image : le fichier redevient visible sous le gestionnaire de fichier. Mais quand on veut l'ouvrir, un message d'erreur s'affiche.

> C'est logique, au niveau de la FAT, les anciens clusters du fichier sont marqués comme étant libre. Donc, le SGF n'arrive pas à recoller les morceaux. Donc, il nous faut déterminer la liste des secteurs appartenant à notre fichier.

> Il va falloir réfléchir. Le fichier faisait 10 Ko donc il devait occuper 20 secteurs. Il a été créé juste après la création des 2 répertoires. Donc, le S.E lui a attribué le premier cluster libre à savoir le cluster N° 4 (Nomcourt ayant le N°2, NomLong le N°3). Le cluster 4 correspond au secteur physique 35 (4+31). Le fichier doit se terminer dans le cluster 23 (secteur 54). dfCreaFic crée les fichiers en indiquant dans le premier secteur "Debut", dans le dernier secteur "Fin" et dans les secteurs intermédiaires "Suite". Un regard avec HexworkShop aux secteurs 35 et 54 nous confirmera si nous voyons juste.

> Commentaire : là, nous sommes dans un cas facile puisque le fichier est un fichier texte et nous connaissons son contenu. Dans la "réalité", il faut connaître des bouts de phrases, de messages ... du fichier effacé et utiliser la fonction recherche de l'éditeur hexadécimal pour identifier la liste des numéros des secteurs qui constituaient le fichier à reconstruire.

> Donc, nous pouvons compléter le tableau suivant :

> Morceau N° | Secteur N° | Cluster N° |  | Morceau N° | Secteur N° | Cluster N°
> 1 | 35 | 4 | 11 | 45 | 14
> 2 | 36 | 5 | 12 | 46 | 15
> 3 | 37 | 6 | 13 | 47 | 16
> 4 | 38 | 7 | 14 | 48 | 17
> 5 | 29 | 8 | 15 | 49 | 18
> 6 | 40 | 9 | 16 | 50 | 19
> 7 | 41 | 10 | 17 | 51 | 20
> 8 | 42 | 11 | 18 | 52 | 21
> 9 | 43 | 12 | 19 | 53 | 22
> 10 | 44 | 13 | 20 | 54 | 23

Étape 12 : reconstruire la FAT

> Maintenant, il faut calculer les valeurs qu'il faudra remettre dans la FAT pour reconstruire le chaînage. Si nous considérons les 9 secteurs de la FAT comme un seul tableau de [0 ; 4607] octets. Nous avons eu une idée de programme (ID PG) qui nous permettait de calculer les adresses des octets à lire dans la FAT en fonction du numéro de cluster que l'on veut suivre (voir dans la partie complément), là les modifications devant être effectuées via hexworkshop, il faut identifier le numéro du secteur et l'adresse dans ce secteur pour chaque entrée à modifier.

> NuméroSecteurFatALire = PartieEntière[(NumeroCluster * 1.5) / 512] +1

> AdresseOctetDansLeSecteur = (PartieEntière[(NumeroCluster * 1.5)] - [512 * (NuméroSecteurFatALire -1)]

> Si nous appliquons cela à notre cas, nous pouvons compléter le tableau suivant :

> N°Cluster | N°Secteur FatALire | AdresseOctet DansLeSecteur | Adresse Hexa |  | N°Cluster | N°Secteur FatALire | AdresseOctet DansLeSecteur | Adresse Hexa
> 4 | 1 | 6 | 06 |  | 14 | 1 | 21 | 15
> 5 | 1 | 7 | 07 |  | 15 | 1 | 22 | 16
> 6 | 1 | 9 | 09 |  | 16 | 1 | 24 | 18
> 7 | 1 | 10 | 0A |  | 17 | 1 | 25 | 19
> 8 | 1 | 12 | 0C |  | 18 | 1 | 27 | 1B
> 9 | 1 | 13 | 0D |  | 19 | 1 | 28 | 1C
> 10 | 1 | 15 | 0F |  | 20 | 1 | 30 | 1E
> 11 | 1 | 16 | 10 |  | 21 | 1 | 31 | 1F
> 12 | 1 | 18 | 12 |  | 22 | 1 | 33 | 21
> 13 | 1 | 19 | 13 |  | 23 | 1 | 34 | 22

> Attention, il ne faut pas oublier qu'il faut lire 2 octets pour en extraire 1,5 octets (12 bits). Dans le tableau nous avons calculé l'adresse du premier des 2 octets à lire.

> Avant de continuer, il faut vérifier que les octets situés aux adresses trouvées sont "marqués" comme disponible avec la valeur 0x000. Cela permet de vérifier que nous sommes sur la bonne voie.

> Le calcul doit se faire progressivement. De plus 2 entrées successives (paire-impaire) sont imbriquées. Donc il faut raisonner sur 3 octets.

> Si nous attribuons une lettre à chaque caractère hexadécimal du bloc de 3 octets. Cela constituerait A, B, C, D, E et F.

> Pour décoder une entrée paire, on prend ABCD. On inverse les octets. L'ordre est maintenant CDAB. On applique IdPG, il reste DAB. Le numéro du cluster suivant est le décodage en base 10 de DAB qui est en Hexa.

> Pour décoder une entrée impaire, on prend CDEF. On inverse les octets. L'ordre est maintenant EFCD. On applique IdPg, il reste EFC. Le numéro du cluster suivant est le décodage en base 10 de EFC qui est en Hexa.

> Pour calculer les valeurs qu'il faudra remettre dans les secteurs de la FAT, nous utiliserons le tableau suivant. Il devra être rempli selon l'ordre suivant :.

- indiquer le numéro de 2 clusters (exemple 4, 5)
- indiquer le numéro des clusters suivants (ici 5,6)
- dans la ligne du cluster pair (ici 4), écrire le numéro du cluster suivant sur 3 caractères hexadécimaux précédés de * , ici *005 dans la colonne IdPG
- reporter dans les cases A, B et D les valeurs correspondantes (ici A=0, B=5 et D=0)
- dans la ligne du cluster impair (ici 5), écrire le numéro du cluster suivant sur 3 caractères hexadécimaux suivis de * (ici 006*) dans la colonne IdPG
- reporter dans les cases C, E et F les valeurs correspondantes (ici C=6, E=0 et F=0)
- regrouper les résultats des deux lignes. Cela donne les trois octets pour les 2 clusters (ici 05-60-00).

> | 1 case par caractère hexadécimal | Paire Impaire | IdPG |
> N°cluster | A | B | C | D | E | F | C E | D F | A C | B D | *DAB EFC* | N° cluster Suivant
> 4 | 0 | 5 |  | 0 |  |  |  |  |  |  | *005 | 5
> 5 |  |  | 6 |  | 0 | 0 |  |  |  |  | 006* | 6
> | 0 | 5 | 6 | 0 | 0 | 0 |  |  |  |  |  |

> Continuons pour les autres valeurs. Cela donne :

> | 1 case par caractère hexadécimal | Paire Impaire | IdPG |
> N°cluster | A | B | C | D | E | F | C E | D F | A C | B D | *DAB EFC* | N° cluster Suivant
> 6 | 0 | 7 |  | 0 |  |  |  |  |  |  | *007 | 7
> 7 |  |  | 8 |  | 0 | 0 |  |  |  |  | 008* | 8
> | 0 | 7 | 8 | 0 | 0 | 0 |  |  |  |  |  |
> 8 | 0 | 9 |  | 0 |  |  |  |  |  |  | *009 | 9
> 9 |  |  | A |  | 0 | 0 |  |  |  |  | 00A* | 10
> | 0 | 9 | A | 0 | 0 | 0 |  |  |  |  |  |
> 10 | 0 | B |  | 0 |  |  |  |  |  |  | *00B | 11
> 11 |  |  | C |  | 0 | 0 |  |  |  |  | 00C* | 12
> | 0 | B | C | 0 | 0 | 0 |  |  |  |  |  |
> etc .... |  |  |  |  |  |  |  |  |  |  |  |
> 22 | 1 | 7 |  | 0 |  |  |  |  |  |  | *017 | 23
> 23 |  |  | F |  | F | F |  |  |  |  | FFF* | Fin
> | 1 | 7 | F | 0 | F | F |  |  |  |  |  |

> Il nous reste à écrire dans le secteur 1 de la FAT à partir de l'octet d'adresse 0x0006 jusqu'à l'octet 0x0023 inclus.

> reconstruction de la FAT

Étape 13 : la FAT 2 est-elle utile ?

> Après tout cela, essayons d'ouvrir le fichier COU-001.TXT. Cela fonctionne. Le fichier est bien restauré. Mais au fait, n'existe-t-il pas une copie de la FAT ? Que contient-elle ? Nous ne l'avons pas modifié. Regardons avec hexworkshop le secteur N°10 qui est "normalement" la copie du secteur 1.

> Commentaire : la copie de la FAT n'est pas vraiment "efficace". Bien que cela nous arrange dans le cas présent, puisque nous n'avons pas eu à le mettre à jour.

> Question : quand la synchronisation entre les deux FAT sera refaite ?

> Réponse : dès que l'espace disque attribué au fichier COU-001.TXT sera modifié.

> Si on modifie le contenu du fichier COU-001.TXT (par exemple en remplaçant "Debut" par "DEBUT") cela ne resynchronise pas les deux FAT. Supprimons une partie du fichier pour qu'il soit plus petit d'un cluster.

> Cela entraine une resynchronisation des 2 FAT.

> Commentaire : Puisque la réparation a fonctionné en modifiant uniquement la FAT 1 sans la FAT 2, cela fonctionnerait-il aussi dans l'autre sens ? A priori, NON, j'ai essayé en remettant les entrées de FAT 1 à 0 et en laissant les bonnes valeurs dans FAT 2. Le système d'exploitation refuse d'ouvrir le fichier.

Étape 14 : écrasement de fichier

> Supprimons COU-001.TXT et créons avec dfCreaFic un fichier DIM-001.TXT de 512 octets à la racine de la disquette.

> Question : où le fichier va-t-il physiquement être créé ? Dans le premier cluster disponible ou dans le cluster suivant le dernier cluster occupé ?

> Réponse : en regardant avec hexworkshop le secteur 1 de la FAT, nous constatons que le premier cluster disponible (libéré suite à l'effacement de COU-001.TXT) a été attribué. L'entrée dans la RootDirectory nous le confirme ainsi que le contenu du cluster 4 (secteur 35) qui contenait un morceau de COU-001.TXT.

> Commentaire : Ceci explique pourquoi on dit toujours : "Si un fichier est effacé par erreur il ne faut pas travailler sur le support pour éviter que des morceaux soient écrasés physiquement par de nouvelles données".

Étape 15 : lenteur du lecteur de disquette

> Actuellement, il reste 31 232 octets de libres sur la disquette. J'envisage de créér 218 fichiers de 32 octets à la racine.

> Question : est-ce possible ?

> Réponse : évidemment NON (sinon je ne l'aurais pas posé). En effet la place nécessaire n'est pas égale à 6 976 octets (218 * 32) mais à 111 616 octets (218 secteurs) puisque le plus petit espace alloué fait au minimum 1 cluster.

> Donc libérons de la place en supprimant le fichier situé dans le répertoire NomLong. Créons nos 218 fichiers de 32 octets avec dfCreaFic. Les noms seront RAC-001.TXT à RAC-218.TXT. Vérifier bien que les 218 fichiers existent bien.

> L'écriture sur des secteurs non identifiés "défectueux" n'est pas détectée pas le programme. Voilà pourquoi au début nous avions fait un CHKDSK /F.

> Commentaire : un lecteur de disquette c'est vraiment trop long.

> Il nous reste 841 216 octets de libres (1643 secteurs).

Étape 16 : les limites de la Root Directory

> Pour en finir avec cette disquette, ou presque, créons un dernier fichier de 1 octet (pour aller plus vite) appelé BUG-001.TXT. Vérifions bien avant de confirmer la création. |

> Je crois que nous aurions du choisir un autre nom. Le programme refuse de créer le fichier.

> Question : pourquoi refuse-t-il ?

> Réponse : le problème n'est pas lié à l'espace physique mais au fait que nous voulons créer ce fichier sous la racine. Il ne faut pas oublier que toute création sous la racine entraîne l'écriture de blocs de 32 octets décrivant l'objet créé. Pour cela le réperoire racine dispose d'un espace limité. Le secteur de Boot indique dans la zone à l'adresse 0x11h : "Nombre d'entrées possibles dans le répertoire racine : 224". Si nous complétons le tableau suivant, nous pouvons mettre en évidence le nombre d'entrées déjà occupées :

> Objet | Nb Entrée courte - DOS 8+3 | Nb Entrée LFN | Sous-total
> Nomcourt | 1 | 1 | 2
> NomLong | 1 | 1 | 2
> DIM-001.TXT | 1 | 0 | 1
> RAC-001.TXT à RAC-218.TXT | 218 | 0 | 218
> |  | Total | 223

> A priori, il devrait en rester UNE. Mais, l'attribution d'un label occupe aussi une entrée. Donc, il ne reste plus de place. Un simple regard sur le premier secteur de la Root Directory ( N°19) et sur le dernier secteur de la Root Directory (N°32), nous confirme cela.

> Pourtant les secteurs de la FAT sont pleins de clusters libres (voir dans les secteurs 4 à 9).

> Commentaire : si nous avions créé sous la racine des fichiers avec des noms longs, cela aurait réduit encore plus le nombre de fichiers physiques enregistrables à la racine du disque.

Étape 17 : formatage rapide

> Pour terminer nos expériences, nous allons reformater la disquette en cochant la case "formatage rapide". Commentaire : c'est vraiment du rapide. Question : quelles sont les modifications effectuées en si peu de temps ? |

> Réponse : un regard aux secteurs de la partie DATA de la disquette nous montre qu'aucune donnée n'est effacée.

> En fait, le formatage rapide a réinitialisé la FAT 1, la FAT 2 et la Root Directory "uniquement".

Voilà, nous avons terminé les étapes. Ouf .. ;-)).