Systemkollaps

[Der Martin]

Hallo Tom,

Am Anfang hängen alle verfügbaren Cluster als verkettete Liste hintereinander.

nein, das ist ein falscher Ansatz. Die verfügbaren (also nicht belegten) Cluster liegen vielmehr als Haufen beisammen, ganz gewiss aber nicht als Kette. Verfügbare Cluster sind in der FAT immer mit 0 gekennzeichnet. Da die Cluster-Numerierung mit 2 beginnt, ist diese Kennzeichnung eindeutig von "richtigen" Folgeclusternummern unterscheidbar.

Je nachdem, ob FAT12, FAT16 oder FAT32 verwendet wird, ergeben sich die Zuordnungen
  Cluster<->FAT-Eintrag
direkt aus der Position in der FAT (position equals cluster number) oder eben über Berechnung.

Nein, diese Zuordnung ergibt sich *immer* aus der Position in der FAT.

Zumindest ist jedem "Datensatz" in der FAT direkt ein Cluster zugeordnet.

Ja, das auf jeden Fall.

Wenn nun eine neue Datei im Verzeichnis angelegt werden soll, wir erst geschaut, ob es gelöschte Files gibt (Erstens Zeichen = 0x05, wenn ich nicht irre) und die dann wiederverwendet.

Ja; in alten DOS-Zeiten, als Dateinamen noch keine Sonderzeichen >0x80 enthalten durften, wurde ein freier Eintrag auch mit 0xE5 markiert.

Die Fileinformationen stehen in Directory-Files, die zu Datensätzen à 32 Bytes organisiert sind.

Richtig. Als kleines Schmankerl noch: Für den "langen" Dateinamen werden zusätzliche 32byte-Records im Verzeichnis verwendet, so dass ein kompletter Verzeichniseintrag dann auch z.B. 5 oder 8 dieser 32byte-Records belegen kann.

Wenn nun ein File gelöscht wird, wird _nicht_ die Clusterkette zurückgegeben an die Hauptkette, sondern sie belibt ungenutzt liegen, bis zufällig in diesem Directory wieder ein File angelegt werden soll.

Du meinst die Clusterkette, die das Verzeichnis selbst enthielt? Dann ist es richtig. Denn die Clusterkette, die den Dateiinhalt aufnahm, wird sehr wohl wieder dem Pool der freien Cluster zugeordnet (FAT-Eintrag: 0).

Was passiert aber nun mit der Restcluster-Kette, wenn das neue File weniger Platz benötigt, als das alte? Die könnte nämlich erstens als "Luschenfile" im Directory verbleiben, oder aber sie könnte der Hauptclusterkette zurückgegeben werden.

Hä? Jetzt wird's geheimnisvoll. Welche Restcluster-Kette meintest du nun wirklich? Die der Datei selbst? Die gibt es nach dem Löschen nicht mehr. Die freien Cluster bilden keine Kette, siehe oben. Das ist mit ein Grund, warum das Rekonstruieren gelöschter Dateien manchmal problematisch ist, selbst wenn seit dem Löschen nichts mehr auf diesem Volume geschrieben wurde: Aus dem noch lesbaren Verzeichniseintrag kann man Startcluster und Dateigröße ablesen. Aber es ist nicht sicher, dass die Folgecluster (diese Info fehlt jetzt nach dem Löschen) systematisch fortlaufend belegt wurden. Eine Datei kann durchaus die Cluster 422,423,424,616,81,82 und 83 in genau dieser Reihenfolge belegen. Sowas ist hinterher praktisch nicht mehr automatisch rekonstruierbar.

Soviel Zeit hatte ich aber weder gestern noch heute, dies qualifiziert in
http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx
nachzulesen.

Boah. Ich wusste gar nicht, dass Microsoft diese Spec nun offiziell zur Verfügung stellt. Ich habe vor ein paar Jahren mal entsprechende Info gesucht, da gab's aber nichts. Man war als Programmierer darauf angewiesen, durch Experimente und Analyse selbst herauszufinden, wie's läuft.
Werde ich mir in einer ruhigen Stunde sicher mal durchlesen, danke für den Hinweis.

Übrigens haben mich Svens und Martins Betrachtungen noch auf neue gute Ideen gebracht, ...
Die Identifikation der untersuchten Files wird immer besser :-))

Danke, das höre ich gern. Dann würde mich das Endergebnis aber auch irgendwann interessieren!

So long,
 Martin