Verhindern von zerstörten Aufnahmen nach Verifying files...

[FireBird]

Die fatalen Crashes entstehen dann, wenn, aus welchem Grund auch immer, falsche Daten über die FAT geschrieben werden. Ich habe dort schon Teile von Aufnahmen gefunden. Dann hilft Dir Filer auch nicht mehr, da dessen Datenbank nicht mehr einfach auffindbar ist. Das Backup-TAP muss also einen Trick anwenden, damit die Daten vom Restore-TAP auch gefunden werden. Das Restore-TAP kann natürlich die Filer2-DB verwenden, damit es die Verzeichnisstruktur nicht abgrasen muss.

[rom27]

Das wär dann wohl ein ganz schön schwieriges TAP, bzw. deren zwei. Schade, ich hätte gedacht, dass es da vielleicht einen einfachen Weg gibt. So nach dem Motto "Copy FAT to FILE", "Read FAT from FILE" - fertich.

Mit dem Trick meinst Du sowas wie das FAT-File immer an bestimmten Adressen auf der Platte ablegen. Sprich sagen wir aus einer Liste von 100 vordefinierten Segmenten das erste freie zur Ablage verwenden und an den gleichen Adressen wieder nach dem FAT-File suchen. Und das FAT-File natürlich mit einer eindeutigen Kennung in den ersten Bytes. Oder?

[FireBird]

So nach dem Motto "Copy FAT to FILE", "Read FAT from FILE" - fertich.

So ähnlich beginnt jedes Programm... :

Mit dem Trick meinst Du sowas wie das FAT-File immer an bestimmten Adressen auf der Platte ablegen.

Genau.

[rom27]

Ich nehm mal an, dass der Filer das, was wir hier grad besprechen, nicht beherrscht, oder?

Wenn ich die Zeit dazu hätte mich einzuarbeiten und mehr Übung mit dem Programmieren wär das ja ganz reizvoll. Aber ersteres hab ich nicht und zweiteres hab ich seit einigen Jahren auch nicht mehr gemacht. Also wird das wohl nix, aber zumindest in der Theorie würds gehen - ist ja auch schön.

Meinst Du übrigens, dass über die FAT falsche Daten drübergeschrieben werden, oder über die Verzeichniseinträge? Über die FAT, die ja meines Wissens auf der Platte an einer ganz bestimmten Stelle liegt, wird ja hoffentlich kein noch so subversiver Code drüberschreiben.

[FireBird]

Ich nehm mal an, dass der Filer das, was wir hier grad besprechen, nicht beherrscht, oder?

Nein. Was der Filer macht, ist dass er von Zeit zu Zeit die Firmware dazu veranlasst, die FAT vom Speicher auf die Disk zu schreiben. Damit verhindert man 0-Byte-Dateien nach einem Crash während einer Aufnahme.

Meinst Du übrigens, dass über die FAT falsche Daten drübergeschrieben werden, oder über die Verzeichniseinträge?

Möglich ist alles, bei der FAT ist es fataler.

Über die FAT, die ja meines Wissens auf der Platte an einer ganz bestimmten Stelle liegt, wird ja hoffentlich kein noch so subversiver Code drüberschreiben.

Der subversive Code nennt sich Firmware. Ist aber wurscht, ob er aus Frankreich oder Russland importiert wird. Warum es passiert, weiß man nicht. Dazu passiert es einfach zu selten, um es genauer analysieren zu können.

[rom27]

Die 0 Byte Aufnahmen bei einem Stromausfall während der Aufnahme find ich nicht besonders schlimm. Im besten Fall hätte man eh nur eine teilweise Aufnahme der Sendung bis zum Ausfall. Einzig wenns während des Nachlaufs passiert find ichs ein bisschen ärgerlich, aber es betrifft ja nur die eine Aufnahme.

Über die FAT schreiben find ich pervers und hab ich noch nie gehört . Wenn es diesbezüglich französische oder russische Erfahrungsberichte gibt, dann kann ich die wenigstens nicht lesen.

Bei mir dürfte es bei meinem Problem vor einigen Wochen 2 Verzeichniscluster erwischt haben, die geschrottet worden sind. Weil bis auf diese beiden Verzeichnisse war eigentlich noch alles in Ordnung. Trotzdem hab ich dann alles wichtige auf den PC geholt und formatiert.

Jetzt lass ich alle Aufnahmen im Root liegen. Ich hab zwar eine 500er Platte (in echt nur 465 GB), und da werden es schon 100-200 Einträge werden wenn sie voll wird - aber das find ich trotzdem nicht schlimm.

Das Root ist meiner Meinung nach das sicherste Verzeichnis und wenn das mal geschrottet ist, dann ist dem Dateisystem eh nicht mehr zu helfen (außer mit einem FAT-Rescue-TAP wie oben beschrieben).


Gibts bei FAT24 eigentlich eine Beschränkung bei der Anzahl der Root-Einträge?
Liegen die Verzeichniscluster fürs Root direkt nach der FAT?
Gibts im Netz irgendwo eine sinnvolle Doku über FAT24?
Ist das von Topfield verwendete FAT24 etwas genormtes oder Topfield-eigenes?

[FireBird]

Gibts bei FAT24 eigentlich eine Beschränkung bei der Anzahl der Root-Einträge?

Ja.

Liegen die Verzeichniscluster fürs Root direkt nach der FAT?

Cluster, ja. Aber da liegen schon eine Menge Sektoren dazwischen. Im Speicher nicht.

Gibts im Netz irgendwo eine sinnvolle Doku über FAT24?

Ja.

Ist das von Topfield verwendete FAT24 etwas genormtes oder Topfield-eigenes?

Letzteres.

[rom27]

Und schon wieder einer, den es erwischt hat. Siehe Thread viewtopic.php?t=24750 - genau um das Problem ging es mir bei diesem Thread.

Frage an Firebird:
Bzgl. Anzahl der Root Einträge - wieviele sind max. möglich?
Bzgl. Doku über FAT24 - wo findet man die Doku (Link)?

[FireBird]

Bzgl. Anzahl der Root Einträge - wieviele sind max. möglich?

Die Frage ist nicht so leicht zu beantworten. Theoretisch sollten 1 Cluster (ist z.B. 2444 Sektoren bei einer 160GB HDD = 1251328 Bytes) dividiert durch 128 Bytes pro Eintrag (= 9776 in unserem Beispiel) Einträge möglich sein. Bei Unterverzeichnissen spricht vom Dateisystem nichts gegen ein Verzeichnis, das mehr als einen Cluster einnimmt. Praktisch gibt es aber einige MP3-Liebhaber, die von seltsamen Abstürzen berichten, lange bevor sie das Cluster-Limit erreicht haben. Im Root? Wer speichert schon im Root (DataFiles, ProgramFiles, MP3 sind keine Root-Verzeichnisse)?

Bzgl. Doku über FAT24 - wo findet man die Doku (Link)?

Nimm den.

[rom27]

Datafiles ist ja nicht Root. ops: