CheckFAT: Festplatten-Dateistruktur überprüfen

Wie bereits aus [1] bekannt ist, können logische Fehler auf einem Medium zum Teil gravierendere Folgen nach sich ziehen als physikalische. Im folgenden Artikel werden die möglichen Fehler und Methoden zu ihrer zuverlässigen Erkennung vorgestellt. Darüber hinaus wird ein Programm zur FAT-Prüfung geboten, das sowohl für den Autoordner als auch für den Einsatz vom Desktop oder einer Shell aus geeignet ist.

Für das Verständnis des Artikels ist eine gewisse Grundkenntnis über die Datenverwaltung des GEMDOS mit Hilfe der FAT dringend notwendig; wer diese nicht hat, erhält unter anderem in [2] oder [3] ausführliche und gut verständliche Informationen.

Welche Fehler sind möglich?

Der (meistens) harmloseste und auch am häufigsten auftretende Fehler sind verwaiste Cluster. Sie sind in der FAT als belegt gekennzeichnet, gehören aber zu keiner Datei/zu keinem Ordner. Die häufigste Ursache für verwaiste Cluster sind nicht ordnungsgemäß geschlossene Dateien, beispielsweise wenn ein Programm beim Schreiben abgestürzt ist. Sie können aber auch entstehen, wenn ein „amoklaufendes“ Programm Verzeichnisinformationen überschreibt.

Verwaiste Cluster haben im allgemeinen keine schwerwiegenden Folgen für die restlichen Daten der Platte, belegen jedoch unnötig Platz, der dann unter Umständen gerade beim Speichern wichtiger Daten fehlt. Daher sollte man sie so bald wie möglich mit einem passenden Disk-Utility (z.B. SED von der Kleisterscheibe oder Diskus) in einer Datei sammeln, begutachten (eventuell sind noch brauchbare Daten enthalten) und dann gegebenenfalls löschen.

Eine weitaus unangenehmere Gattung der FAT-Fehler sind mehrfach belegte Cluster, sie sind also mehr als einer Datei zugeordnet. Direkte Folge davon ist natürlich, daß höchstens eine dieser Dateien noch korrekte Daten enthält, da sie ja alle ab einem bestimmten Punkt den gleichen Inhalt haben. Eine brauchbare, aber naturgemäß nicht 100%ig sichere Methode, herauszufinden, welche Datei in Ordnung ist, ist der Längenvergleich, doch dazu später. Weist die FAT mehrfach belegte Cluster auf, kann bereits das nächste Löschen einer Datei wichtige Daten vernichten, man sollte also alle Schreibzugriffe vermeiden (das gilt auch für alle im folgenden genannten Fehler).

Meistens direkt im Zusammenhang mit mehrfach belegten Clustern treten Cluster mit mehreren Vorgängern auf. Im Normalfall gibt es zu jedem belegten Cluster höchstens einen, der auf diesen zeigt. Sind aber Cluster mehrfach belegt, hat einer von ihnen in der Regel auch mehrere Vorgänger (wenn nicht, haben die betroffenen Dateien den gleichen Startcluster, oder die Startcluster zeigen in die Kette einer anderen Datei). Es kann aber auch sein, daß ein verwaister Cluster auf einen inzwischen anderweitig belegten zeigt, dieser hat dann eben auch keinen eindeutigen Vorgänger.

Illegale Cluster-Verweise sind meist die Folge von fehlerhaft geschriebenen FATs, beispielsweise durch einen unbrauchbaren Festplatten-Optimizer. Gültige Cluster-Nummern gehen von 2 bis zur Anzahl der Datencluster + 1 (bei älteren GEMDOS-Versionen nur bis Datencluster - 1); hat ein FAT-Eintrag also einen Wert außerhalb dieses Bereichs (und er ist nicht leer oder Kennzeichen für Dateiende oder „Cluster defekt"), ist der Verweis ungültig. Die Datei, die zu diesem Cluster gehört, ist damit natürlich ebenfalls unbrauchbar, da die Verkettung an dieser Stelle zerbrochen ist.

Besonders üble Zeitgenossen sind Cluster-Schleifen. Bei diesem Fehlertyp zeigt ein Cluster innerhalb der Verkettung auf einen bereits vorher erreichten, was äußerst ungünstige Folgen haben kann. Ein echtes Dateiende haben davon betroffene Files natürlich nicht mehr, daher ist ihr Inhalt in den meisten Fällen unbrauchbar geworden. Zwar lädt das GEMDOS nur die für die angegebene Dateilänge nötige Anzahl von Clustern und bleibt daher nicht in solchen Schleifen hängen, besonders gesund ist es jedoch trotzdem nicht, zumal sich Schnellkopierprogramme, die Files unter Umgehung von GEMDOS kopieren, hieran durchaus verschlucken können.

Ebenfalls mit zum Teil bombigen Folgen behaftet sind Ordnerschleifen. Hier zeigt der Start- oder ein Folge-Cluster eines Verzeichnisses auf einen Cluster, der bereits von einem der übergeordneten Ordner belegt ist. Beim Öffnen dieses Directories kommt man also wieder an eine Stelle, an der man schon war, es liegt also eine hübsche Endlosschleife vor, die z.B. die Ordner-Info der meisten Desktops zum Absturz bringt. Dieser Fehler ist zugegebenermaßen selten, sollte aber trotzdem erwähnt werden.

Es gibt Programme, die eine Festplattenpartition auf defekte Sektoren testen und eventuell betroffene Cluster in der FAT als defekt markieren. Leider prüfen nicht alle, ob dieser Cluster bereits belegt ist und wenn ja, von welcher Datei. Somit werden unter Umständen Dateien einfach abgeschnitten, da in ihrer Cluster-Kette ein Eintrag vorkommt, der einen defekten Cluster markiert, was vom GEMDOS wie ein Dateiende interpretiert wird. Solche Fehler bemerkt man unter Umständen erst zu spät (als Nebenprodukt können dabei übrigens auch verwaiste Cluster entstehen).

Im engen Zusammenhang mit solchen „abgewürgten“ Dateien stehen Differenzen zwischen eingetragener Dateilänge und der tatsächlichen Anzahl belegter Cluster, d.h., die Datei enthält laut Inhaltsverzeichnis mehr oder weniger Cluster, als dies wirklich der Fall ist. Dies kann aber auch auf-treten, wenn Cluster mehrfach belegt sind, da in diesem Fall ja nur noch eines der beteiligten Files (wenn überhaupt) die korrekten Cluster belegt. Stimmt also die eingetragene Dateilänge nicht mit der tatsächlichen überein, kann dies auch ein Indiz dafür sein, daß die Datei zu einer Gruppe von Files gehört, die gemeinsame Cluster belegen und somit unbrauchbar ist. Umgekehrt stehen die Chancen gut, daß die Datei noch in Ordnung ist, wenn sie zu einer solchen Gruppe gehört, aber trotzdem die korrekte Länge hat. Absolut sicher ist dies natürlich nicht, es stellt aber zumindest eine einigermaßen brauchbare Prüfmöglichkeit dar.

Im Zusammenhang mit FAT-Fehlern sei auch dringend vom Gebrauch von Disk-Optimizern abgeraten, wenn vorher nicht eine umfangreiche Prüfung der FAT stattgefunden hat (das sollte der Optimizer eigentlich selbst erledigen). Läßt man ein solches Programm nämlich auf Platten mit einer fehlerhaften FAT los, kann man fast sicher sein, daß man hinterher nur noch wertloses Datendurcheinander vorfindet.

Testverfahren

Nachdem die möglichen Fehler aufgezeigt wurden, folgt nun eine Vorstellung von Verfahren, um ihnen auf die Schliche zu kommen. Als „Zugabe“ gibt es CheckFat, einen FAT-Prüfer für Festplatten, der alle genannten Fehlertypen schnell und zuverlässig findet. Beheben kann er sie jedoch nicht, dafür ist dann ein geeignetes Disktool erforderlich, zumal sich die meisten FAT-Fehler nicht ohne „Handarbeit" korrekt entfernen lassen.

Unerläßlicher Bestandteil einer vollständigen FAT-Prüfung ist es, den gesamten Dateibaum durchzugehen und jeden von einer Datei belegten Cluster in einer Tabelle zu vermerken. Allein dadurch lassen sich schon verwaiste Cluster finden, denn diese sind zwar in der FAT, nicht aber in der Tabelle als belegt gekennzeichnet.

Setzt man beim Durchgehen der Cluster nicht nur ein Flag für „belegt“ in der Tabelle, sondern benutzt die Einträge alsZähler, können auch mehrfach benutzte Cluster gefunden werden. Im gleichen Arbeitsgang kann man auch illegale Start- und Folge-Cluster finden, Files bzw. Ordner aufspüren, die durch einen defekten Cluster abgewürgt wurden, sowie unterschiedliche Dateilängen aufdecken.

Möchte man Cluster-Schleifen aufspüren, ist ein wenig mehr Aufwand nötig (prüft man nicht, würde die Routine zum Durchlaufen des Dateibaums unweigerlich hängen bleiben). Man könnte nun einfach von einer Schleife ausgehen, wenn der nächste Cluster in der Tabelle schon als belegt vermerkt wurde, damit verliert man aber die Möglichkeit, durch verschiedene Dateien mehrfach belegte Cluster zu erkennen. Eine zuverlässige Methode ohne diesen Nachteil ist es, eine zweite Tabelle zu führen und dort für jeden Cluster zu vermerken, von welchem File er belegt ist (dazu muß man natürlich jeder Datei ein individuelles Kennzeichen geben, am einfachsten eine Nummer, die bei jeder neuen Datei um eins erhöht wird). Trifft man nun beim Durchlaufen der Cluster eines Files auf einen, der bereits von eben dieser Datei belegt wurde, liegt eine Schleife vor, und man muß abbrechen.

Ordnerschleifen lassen sich mit einem relativ einfachen Trick zuverlässig erkennen: Man merkt sich, welchen Start-Cluster die bisherigen Ordner des aktuellen Pfades hatten und prüft, ob der Start-Cluster des neuen Verzeichnisses bereits vorkam. Wenn ja, hängt man in einer Ordnerschleife und muß abbrechen. Mit dieser Erkennungsmethode findet man nur Ordnerschleifen, bei denen Start-Cluster auf Start-Cluster verweist, auf Anhieb. In anderen Fällen „tappt“ die Routine einmal in die Falle, bevor die Schleife erkannt wird. Allerdings kann man das sicherlich leicht verschmerzen, da der Programmier- und Zeitaufwand für eine absolut sichere Soforterkennung weit höher liegt.

Um Cluster mit mehreren Vorgängern aufzuspüren, könnte man für jeden Cluster die gesamte FAT durchgehen und prüfen, ob ein Eintrag auf den aktuellen Cluster zeigt. Findet man mehrere, hat der Cluster keinen eindeutigen Vorgänger. Allerdings sollte man sich den dafür nötigen Aufwand genauer betrachten: Es müssen zwei Schleifen verschachtelt werden, die jeweils alle Cluster durchgehen [für Informatiker: der Aufwand wäre also 0(n2)]. Es leuchtet ein, daß das viel zu langsam ist. Glücklicherweise gibt es eine deutlich schnellere Methode, die mit einer Schleife [also O(n)] auskommt: Für jeden Cluster setzt man in einer Tabelle ein Flag an der Stelle seines Folge-Clusters. War dort schon vorher ein Flag, hat eben dieser Folge-Cluster mehrere Vorgänger.

Das Programm CheckFat

Das Handwerkszeug, um eine FAT zu prüfen, ist jetzt beschrieben. Damit es aber nicht nur bei grauerTheorie bleibt, stelle ich noch kurz ,CheckFat“ vor, dessen Quellcode als Anschauungsobjekt dienen kann, aus Platzgründen aber in auf der Redaktionsmailbox (069-292966) zu finden ist (es sind etwas mehr als 900 Zeilen).

CheckFat ist ein Kommandozeilen-Utility, das ein beliebiges Laufwerk mit 16-Bit-FAT überprüfen kann. Die Aufrufsyntax und Returncodes finden sie im nebenstehenden Kasten. Damit ist es ein Leichtes, CheckFat in ein Script einzubinden und auf eventuelle Fehler angemessen zu reagieren. Bei beschädigter FAT bietet es sich beispielsweise an, das betroffene Laufwerk sofort gegen Schreiben zu schützen, bis man den Fehlem mit einem passenden Disktool zu Leibe rückt.

Man sollte CheckFat bei wechselbaren Medien nach einem Datenträgertausch übrigens erst dann aufrufen, wenn man sich im Desktop bereits das neue Inhaltsverzeichnis hat anzeigen lassen, da CheckFat GetbpbQ aufruft und so unter Umständen das Melden eines Medienwechsels an GEMDOS verhindert. Unterbleibt dies nämlich, benutzt GEMDOS noch die alten FAT-Puffer, die Folgen kann sich jeder selbst ausmalen ...

Um CheckFat, wie anfangs versprochen, auch im Autoordner benutzen zu können, benötigt man ein kleines Hilfsprogramm, das CheckFat mit den passenden Parametern aufruft. Listing 1 zeigtein solches Programm, das CheckFat zunächst nur mit dem Laufwerk als Parameter aufruft und bei fehlerhafter FAT die Möglichkeit bietet, CheckFat nochmals mit detaillierterer Ausgabe zu starten. Um unnötigeTests bei Warmstarts zu vermeiden, wird das Autoordnerprogramm nur aktiv, wenn eine der Sondertasten (Shift, Alternate oder Control) gedrückt ist. Wer dieses Verhalten umkehren möchte, braucht im Listing lediglich ein Ausrufezeichen zu entfernen, was an der entsprechenden Stelle auch vermerkt ist.

AutoCFat {so der Name des „Check-Fat-Frontends" für den Autoordner) benötigt eine INF-Datei, die wahlweise im Wurzelverzeichnis des Boot-Laufwerks oder im Autoordner abgelegt werden kann. In ihr werden der Zugriffspfad für CHECKFAT.TTP und die zu prüfenden Laufwerke eingetragen. Listing 2 ist ein Beispiel für diese Datei.

CheckFat ist beim Prüfen trotz hoher Zuverlässigkeit recht flott, so testet es eine 105-MB-Partition mit mehr als 6000 Dateien/Ordnern in weniger als einer halben Minute (ohne Ausgabe, versteht sich). Da man CheckFat im Autoordner wohl nur für die Boot-Partition oder die Partition(en) mit den wichtigsten Daten aufrufen wird, ist eine regelmäßige Benutzung noch nicht einmal extrem zeitraubend. Außerdem ist die dadurch gewonnene Sicherheit nicht in Zeit zu messen.

Literatur:

[1] Uwe Selmet, Datenverlust -Na und? (Teil 3), ST-Computer 06/93, S. 80ff [2] Claus Brod, Anton Stepper, Scheibenkleister II - Massenspeicher am ST,MAXON Computer GmbH, 1989 [3] Jankowskl/Rablch/Reschke, ATARI Profibuch ST-STE-TT, SYBEX-Verlag GmbH, Düsseldorf, 1991