Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Dossier : Pourquoi DiskDoctor était si mauvais ?
(Article écrit par Olaf Barthel et d'Amiga.org - septembre 2017)
|
|
Note : traduction par ScriptJester.
Si vous êtes dans la partie depuis assez longtemps, vous vous rappelez peut-être de l’utilitaire de réparation
de disque livré en "standard" avec le Kickstart/Workbench 1.0 et 2.0 et qui fut abandonné à la sortie du Workbench 2.1.
A chaque fois qu'une erreur survenait sur une disquette, ce qui était relativement courant à cette époque, une
requête AmigaDOS vous demandait de réparer votre disquette avec la commande "DiskDoctor". Beaucoup parmi nous
ont essayé, car il n'y avait quasiment pas d'autre choix, mais peu furent couronné de succès. Il avait une si
mauvaise réputation que c'était devenu une blague récurrente. Vous deviez être vraiment désespéré pour faire
appel à DiskDoctor, car croyez-le ou pas, DiskDoctor laissait le disque dans un pire état qu'avant traitement,
même s'il arrivait parfois à réparer certaines données.
Alors, pourquoi fonctionnait-il aussi mal ? Par curiosité, j'ai effectué quelques recherches cette semaine.
Le but de DiskDoctor était de rendre un volume endommagé à un état de nouveau opérationnel après que
Disk-Validator (le système de validation du disque) ou le système de fichiers de l'Amiga avaient échoué à le faire.
Précisément, DiskDoctor était supposé rendre de nouveau opérationnel Disk-Validator, en repérant la structure
des données du disque, et même en reconstruisant le premier bloc et le répertoire à la racine à partir de zéro.
Pour y arriver, il lisait l'intégralité du disque, pour trouver quel contenu des blocs du disque était encore
sains, et s'il y avait des erreurs de lecture. C'était la première étape où cela pouvait déjà empirer. Si DiskDoctor
trouvait que le premier bloc du disque, ou celui situé à la racine, étaient non lisibles, il réécrivait son contenu
en première approche puis reformatait ces blocs en dernier recours (cela pouvait corriger des "erreurs physiques").
Toutefois, il ne se contentait pas de formater ces quelques blocs, mais l'ensemble de la piste. Vous perdiez
donc non seulement le contenu d'un bloc, mais 11 blocs de données. Comme DiskDoctor réécrivait sur ces blocs avec
ce qu'il y avait dans son tampon mémoire lié à la lecture initiale, les dix blocs détruits étaient remplis de
données aléatoires.
Puis cela allait de mal en pis. En détruisant ces blocs, DiskDoctor pouvait endommager le contenu d'un fichier,
fichier détecté par la suite comme corrompu et donc supprimé par DiskDoctor. La suppression était incomplète
dans la mesure où la structure des données qui permet la lecture du répertoire était elle-même endommagée et
DiskDoctor était alors incapable de comprendre qu'il devrait la réparer. A son tour, cela rendait la validation
du disque inopérante.
Attention, un problème préexistant sur le contenu d'un fichier avait le même effet d’entraînement : DiskDoctor
détectait ce fichier endommagé, mais ne comprenait pas qu'il devrait également réparer les structures des
données du répertoire. Quand un répertoire était endommagé, DiskDoctor ne le réparait jamais.
La version 1.3.3 de DiskDoctor (et probablement celles antérieures aussi) était également affectée d'un
bogue dans le processus initial de recherche. Il ne lisait pas l'intégralité du disque utilisé par le système
de fichiers, oubliant les deux derniers blocs. S'il y avait un fichier ou un en-tête de répertoire stocké
à cet endroit, ou un bloc de données d'un fichier, alors DiskDoctor considérait que ces répertoires n'existaient
pas, ou que les fichiers comprenant ces blocs de données "manquantes" était endommagés.
Dans son processus de réparation, DiskDoctor repérait les fichiers et répertoires dont les répertoires parents
n'avaient plus de répertoire parent valide eux-même. Ils étaient considérés comme des entrées de répertoires
"orphelins", car ils n'étaient plus accessibles par la structure existante de répertoires. Disk-Validator
ajoutait ces orphelins à la racine du répertoire, pour les rendre de nouveau accessibles. Cela parait effectivement
une bonne idée, mais il y avait un problème : si plusieurs fichiers orphelins avaient le même nom, ils apparaissaient
tous à la racine du répertoire. Si vous essayiez de copier le contenu de la disquette "réparée" sur une
nouvelle disquette, comme le recommandait la documentation de DiskDoctor, alors seulement un fichier parmi
ces orphelins de même nom était copié. Essayer de supprimer ces fichiers de même nom sur la disquette "réparée"
amenait probablement à les effacer tous.
Mais, bien sûr, ce n'est pas encore fini. DiskDoctor avait aussi des difficultés pour réparer des fichiers
qui prenaient plus de 72 blocs de données (sur une disquette, c'était au moins 36 865 octets). Résultant
du système de fichiers du système d'exploitation, un fichier sur plus de 72 blocs de données (en considérant
qu'un bloc avait une capacité de 512 octets) avait besoin d'être enregistré dans une autre structure de
données que les autres blocs archivés, appelée la "extension block list" (liste de blocs d'extension).
DiskDoctor se heurtait à une difficulté avec ces blocs d'extension à cause d'une confusion dans les routines
de lecture du disque. Une routine lisait les blocs, vérifiait que le contenu était sain et que le bloc
était d'un certain type. Une autre routine, et dont ce n'était effectivement pas le rôle, ne s'occupait
pas de vérifier tout cela. Le problème était que DiskDoctor utilisait la routine qui vérifiait que ce bloc
était d'un certain type, ce qui amenait à ne pas correspondre avec le type du bloc d'extension. Par conséquent,
DiskDoctor considérait que tous fichiers de plus de 72 blocs étaient non récupérables, ce qui les amenait
inéluctablement à être supprimés. Mais cela avait pour effet indirect d’endommager la structure des répertoires.
Mais ce n'est toujours pas la fin de ce récit. DiskDoctor utilisait une partie incroyable de la mémoire
pour son suivi interne. Pour "réparer" une disquette, ce n'est pas moins de 1760 blocs sur votre Amiga de
512 ko qu'il fallait mobiliser (soit 140 ko). Mais avec un disque dur ayant une partition de 20 Mo, vous
deviez disposer d'au moins 1 Mo de mémoire vive. Au début de l'Amiga, c'était beaucoup demander.
DiskDoctor atteignit le comble de son utilité (selon le sens que l'on donne à "utilité") lorsque l'on
constata qu'il était trop compliqué de le faire évoluer pour l'utiliser avec le nouveau système de fichiers
sorti en 1988, le FastFileSystem (FFS). Commodore s'est débattu pour pallier ces limitations, mais le
problème de base était que la plupart du code de DiskDoctor était spécifique à la structure et au fonctionnement
du système de fichiers du système d'exploitation de l'Amiga.
La configuration des répertoires et des blocs de données est implémentée de façon complètement différente
avec le FFS, mais la confusion régnait toujours. La documentation de la dernière version 1.3.5 de DiskDoctor
encourageait et décourageait à la fois l’utilisateur de l'utiliser sur des partitions FFS. Bien entendu, si
vous étiez assez malchanceux pour essayer, DiskDoctor pouvait rendre des structures de répertoires au format
FFS, qui étaient parfaitement saines, inutilisables avec FFS. Si vous étiez encore plus malchanceux (le
premier bloc du disque étant non lisible), DiskDoctor pouvait considérer que votre partition possédait une
structure de système de fichiers classique et faisait donc comme si : quand il réécrivait les premiers blocs
du disque, c'était avec une structure de données liée au système de fichiers original.
|
