Dateisystem auf CF-Karte

Also schrieb Michael Baeuerle:

Gretchenfrage: Ist die Karte partitioniert (wie eine Festplatte) oder nicht ( = Superfloppy-Format)? Anders gefragt: Bist Du sicher, dass Du Dich auch wirklich in der/einer FAT befindest? Wirf mal ein Linux an, da kannst Du ganz bequem an jedem Bit fummeln... (fdisk -l, dd, xxd, testdisk, ... um mal ein paar Werkzeuge zu nennen)

Ansgar

Die besagte Karte ist partitioniert, die Partition 0 enthaelt das Dateisystem und hat den Typ 0x06. Die Partitionstabelle wird natuerlich auch geprueft: Hat einer der 4 Eintraege im MBR undefinierte Flags gesetzt oder die Partitionen ueberlappen sich, dann wird die Partitiontabelle als ungueltig betrachtet. Das Geraet unterstuetzt aber auch Karten im "Superfloppy" Format, d.h. bei ungueltiger Partitionstabelle wird nicht abgebrochen.

Eigentlich schon, die Partition beginnt bei LBA=32 und dort befindet sich auch der BPB an dem es nichts auszusetzen gibt. Da steht drin MediaType=0xF8 und ReservedBlocks=1. Die erste FAT beginnt also bei LBA=33. Ich habe daher LBA33[0]=0xF8 und LBA33[1]=0xFF (little endian) erwartet.

Linux mountet dieses FS auch und man kann Daten draufkopieren. Total kaputt kann es also nicht sein.

Ich will ja nicht dran rumfummeln, sondern nur pruefen ob die Karte die reingesteckt wurde von diesem Geraet benutzt werden kann oder nicht. Im Gegenteil: Der Algorithmus soll sogar fehlertolerant sein und eine Karte nur dann ablehnen, wenn wirklich kein FAT FS drauf ist. Wenn nur irgendein sowieso unbenutzes Legacy-Bit falsch gesetzt ist soll sie akzeptiert werden.

Micha

die Konvention, den Media-Type aus dem Boot block nochmal in die FAT zu schreiben ist Windows und nicht FAT.

Der konkrete Fehler sieht mir aber eher nach eine falsch berechneten Sektor für die FAT aus. Ich kenne da eher so Werte wie FFF0, FFF7 oder FFFF. Möglicherweise wurden die reservierten Sektoren nicht berücksichtigt.

So weit würde ich jetzt nicht gehen, aber ...

... genau so ist es.

Ein Vergleich FAT1 vs. FAT2 ist mutmaßlich zielführender.

Tipp: bei solchen Aufgaben hat es sich bewährt im Linux-Quellcode zu stöbern. Der FAT16 Filesystemtreiber hat genau die gleiche Hürde zu nehmen.

Marcel

OK, dann ist das wohl prinzipiell keine gute Idee damit herausfinden zu wollen, ob das FS halbwegs intakt ist.

Der Grund warum ich das machen will ist der, dass die Pruefung sich sonst auf den Bootblock beschraenkt (weil da der BPB drin ist). Angenommen jemand "restauriert" den Bootblock mit einem BPB obwohl auf dem Medium eigentlich ein ext2 FS drauf ist. Ein ext2 ist dann nicht kaputt, denn das benutzt den ersten Block nicht. Es waere also schoen wenn man in die Pruefung noch etwas ausserhalb des BPB einbeziehen koennte, so bin ich auf den Gedanken mit dem Media type in der FAT gekommen ...

Doch, in diesem Fall ist es nur einer. Laut MS soll man da bei FAT12 und FAT16 auch nichts anderes als 1 verwenden.

Nach MS Spec ist das falsch - und danach orientiert sich die ganze Welt (dachte ich jedenfalls).

Eigentlich haette ich sowieso lieber ein anderes FS genommen, aber FAT support hat halt jedes heutzutage gaengige OS. Und die Karte soll in diesem Fall an einem Mac befuellt werden. Ausserdem ist FAT bei Lieferung meistens schon drauf, also nochmal weniger Stress fuer den Anwender.

Gute Idee, es sei denn es gibt nur eine FAT. Aber traditionell wurden ja eigentlich immer 2 FATs verwendet. Mein FS hier hat jedenfalls auch zwei.

Habe ich mir gerade mal angesehen. Da war die Pruefung des Media type in der FAT auch mal drin und wurde spaeter auskommentiert mit dem Kommentar: | | But in real world, too many devices is writing | wrong value. So, removed that validity check.

Micha

Ich habe schon mit anderen Werten gearbeitet. Das funktioniert einwandfrei. So ist z.B. ein FAT16 Dateisystem auf einem Medium mit 2k Sektoren binär äquivalent zu einem FAT16 Dateisystem auf einem gleichgroßen Datenträger mit 512b Sektoren, bei dem nur die Cluster- und FAT-Größe und natürlich die reservierte Sektoren um einen Faktor 4 erhöht werden. Damit bringt man auch ältesten Maschinen ein Alignment bei oder ggf. sogar eine andere Sektorgröße.

ja. Wobei da je nach Datenträger durchaus andere Werte reingehörten. (Feld ist von FAT12 geerbt.) Die alten ATARIs haben z.B. was anderes reingeschrieben. Und verschiedene andere vmtl. auch. Besonders Digiknipsen machen gerne mal inkompatible Dateisysteme, respektive fragen auch mal Parameter ab, die nicht einmal Windows garantiert. Und dann es manchmal zur Kunst geraten, ein Formatierprogramm zu finden, was ein für Digiknipse und Lieblingsbetriebssystem lesbares Dateisystem produziert.

Das denken die (und andere, ähnlich große Firmen) auch.

Naja, in dubio würde es halt mal ein Dateisystem mit nominell einer FAT nicht so zielsicher erkennen.

Aufpassen muss man eher, weil manche Dateisysteme vermeintlich ein wenig kompatible Bootblocks verwenden (HPFS, NTFS). Auf die Filesystemsignatur bei Offset 0x36 kann man sich aber normalerweise verlassen.

:-)

Marcel

Marcel Müller :

Stimmt. Erinnert mich an das Superfloppyformat, Sektoren mit 4kBytes Grösse statt 512bytes ein paar mehr Spuren aus der Mechanik rausgequetscht und schon passten 10-20% mehr auf die Floppy drauf. Und das sogar schon zu DOS-Zeiten.

M.

Also schrieb Marcel Müller:

And in real world, too many engineer is writing documentation in poor English.

SCNR

Ansgar

Ja. MS "empfiehlt" auch nur das bei FAT12 und FAT16 so zu machen weil angeblich einige Treiber die 1 hart codiert haben. Sie schreiben explizit dazu, dass ihre eigenen FAT-Treiber auch mit anderen Werten funktionieren. Und bei FAT32 geht 1 ja sowieso nicht.

Meine Digitalkamera mountet da skrupellos alles was man reinsteckt. Ein FS das ihr nicht gefaellt zerschiesst sie einfach kommentarlos. IIRC hat die mir sogar mal mit ihrem FAT Treiber Bilder in ein ext2 kopiert - oder es zumindest versucht, das Ergebnis war logischerweise der GAU fuer die Daten. Genau sowas moechte ich mit den Tests verhindern.

:-)

Genau, damit kann man leben wenn das ein selten vorkommender Fall ist. Bei FAT16 und FAT32 gibt es auch noch Flags im zweiten FAT Eintrag ("cleanly unmounted" und "error"), die will ich auch noch pruefen.

Hmm, aufgrund dieses Feldes moechte ich eigentlich nicht den Mount verweigern. Laut MS gehoert es gar nicht zum FS: | | [...] this field is actually not part of the BPB. | This string is informational only and is not used by Microsoft FS | drivers to determine FAT type because it is frequently not set | correctly or is not present.

Zudem unterstuetzt mein Geraet auch FAT32 und da ist Offset 0x36(...+8) reserviert, weil das Signatur-Feld bei FAT32 einen anderen Offset hat - sonst waere es ja konsistent :-(

Micha