Obligement - L'Amiga au maximum

Jeudi 28 mars 2024 - 17:26  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

Actualité (récente)
Actualité (archive)
Comparatifs
Dossiers
Entrevues
Matériel (tests)
Matériel (bidouilles)
Points de vue
En pratique
Programmation
Reportages
Quizz
Tests de jeux
Tests de logiciels
Tests de compilations
Trucs et astuces
Articles divers

Articles in english


Réseaux sociaux

Suivez-nous sur X




Liste des jeux Amiga

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


Trucs et astuces

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


Glossaire

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


Galeries

Menu des galeries

BD d'Amiga Spécial
Caricatures Dudai
Caricatures Jet d'ail
Diagrammes de Jay Miner
Images insolites
Fin de jeux (de A à E)
Fin de Jeux (de F à O)
Fin de jeux (de P à Z)
Galerie de Mike Dafunk
Logos d'Obligement
Pubs pour matériels
Systèmes d'exploitation
Trombinoscope Alchimie 7
Vidéos


Téléchargement

Documents
Jeux
Logiciels
Magazines
Divers


Liens

Associations
Jeux
Logiciels
Matériel
Magazines et médias
Pages personnelles
Réparateurs
Revendeurs
Scène démo
Sites de téléchargement
Divers


Partenaires

Annuaire Amiga

Amedia Computer

Relec


A Propos

A propos d'Obligement

A Propos


Contact

David Brunet

Courriel

 


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.


[Retour en haut] / [Retour aux articles]