Hallo, ich arbeite zur Zeit mit dem Fats Module von Elm Chan (Fat32) und habe eine Frage zur Dateigröße. Ich schreibe in meine Datei 16Bit-Werte (je 2 Byte). Später, beim Senden übertrage ich die Dateigröße, die mir die Library liefert (Größe in Byte), mit. Dann vergleiche ich die übertragenen Werte mit der Dateigröße zur Prüfung der Plausibilität. Nun ist mit schon klar, dass in der Datei noch mehr steht als nur die reinen Daten. Aber wie bekomme ich die Größe des "Overheads" heraus? Ist die bei Fat32 konstant? Bei zwei unterschiedlichen Dateien hatte ich einmal 32Byte und einmal 56Byte Differenz zwischen Dateigröße und Inhalt. Grüße, Alex
Alexander H. schrieb: > Nun ist mit schon klar, dass > in der Datei noch mehr steht als nur die reinen Daten. Was soll denn da noch drinstehen? Wenn ich 16 Bytes in eine Datei schreibe, dann stehen da auch 16 Bytes drin, nicht mehr und nicht weniger. Da stimmt wahrscheinlich mit Deiner Library etwas nicht.
@ Alexander H. (ill_son) >Ich schreibe in meine Datei 16Bit-Werte (je 2 Byte). Später, beim Senden >übertrage ich die Dateigröße, die mir die Library liefert (Größe in >Byte), Welche Funktion meinst du? > mit. Dann vergleiche ich die übertragenen Werte mit der >Dateigröße zur Prüfung der Plausibilität. Klar. > Nun ist mit schon klar, dass >in der Datei noch mehr steht als nur die reinen Daten. Nö. Was soll da noch drin stehen? >zwei unterschiedlichen Dateien hatte ich einmal 32Byte und einmal 56Byte >Differenz zwischen Dateigröße und Inhalt. Dann hast du irgendwo einen Fehler.
Hallo, danke für die schnellen Antworten. Ich dachte hieran (hab ich eben gefunden): http://www.pjrc.com/tech/8051/ide/fat32.html Wo stehen denn diese Informationen? Ich meine die 32Byte mit Dateiname, Attributen usw. (in der Mitte der Seite). @ Falk: ich lese die FILEINFO, die mir die f_readdir liefert.
Hallo, Asche auf mein Haupt. Habe soeben den Fehler gefunden. Ich habe in meinem Programm unterschiedliche Definitionen für Buffergrößen für die unterschiedlichen Puffer. Ich habe die falsche genommen. Vielen Dank trotzdem für eure Mühe. Grüße, Alex
@ Alexander H. (ill_son)
>@ Falk: ich lese die FILEINFO, die mir die f_readdir liefert.
Das ist OK. Da musst du nicht selber weiter in den Untiefen von FAT
rumsuchen, das macht die Lib von ELM Chan für dich.
Es schadet aber auch nicht zu wissen wie ein Dateisystem auf niederem Level funktioniert. Libs zusammenklicken ist ja dolle in Mode. Fehler zu finden fällt leichter wenn man weiß wie etwas technisch abläuft.
Grundsätzlich stimme ich Dir da voll zu. Allerdings würde ein komplettes Durcharbeiten der Lib den Zeitrahmen für mein Projekt deutlich sprengen. Prinzipiell funktioniert ja alles. Meist ist es ja so, dass man, wenn man eine Funktion verstehen will, am Ende den ganzen Rattenschwanz bis zur untersten Ebene auch verstehen muss und dafür fehlt mit im Moment die Zeit. Grüße, Alex
Wenn Overhead drin steht, dann höchstens trennzeichen und whitespaces (\n\r), wenn du welche benutzt. Alexander H. schrieb: > Dateigröße und Inhalt Eine "Datei" ist immer mind. so groß wie ein Cluster. Wenn du eine Datei hast, wo 96 Byte drin stehen, und ein Cluster ist 4096 Byte groß, dann hat die Datei für das FS eine größe von 4096 Byte, auch dann, wenn wie in dem Beispiel 4000 Byte gar nicht belegt sind. Ein Cluster ist die kleinste einheit die von einem FS verwaltet werden kann. Ansonsten stehen alle Infos zu den Dateien in der FAT.
@ Alexander H. (ill_son) >Grundsätzlich stimme ich Dir da voll zu. Allerdings würde ein komplettes >Durcharbeiten der Lib den Zeitrahmen für mein Projekt deutlich sprengen. Es wäre auch vollkommen VERFEHLT! Wenn man JEDE BLack Box als fehlerhaft betrachten und SOFOR degbuggen würde, würde nie was fertig werden. >Prinzipiell funktioniert ja alles. Meist ist es ja so, dass man, wenn >man eine Funktion verstehen will, am Ende den ganzen Rattenschwanz bis >zur untersten Ebene auch verstehen muss und dafür fehlt mit im Moment >die Zeit. Das ist gar nicht nötig und eher kontraprodutiv. Ich muss nicht Metallurgie studiert haben, um eine Stahlschraube zuu benutzen. Der Kaj hat je eine gute Idee eingebracht. Wenn du die Daten mit f_write schreibst, werden die 1:1 auf der Sd-Karte landen. Wenn du aber aus VErsehen f_puts oder f_printf verwendest, kann es passieren, dass dir die Funktionen ein paar Steuerzeichen unterjubeln. Schreibe eine Datei auf die SD-Karte und schau sie dir am PC mit einem Hexeditor an, dann bist du schlauer.
@ Kaj (Gast) >Eine "Datei" ist immer mind. so groß wie ein Cluster. >Wenn du eine Datei hast, wo 96 Byte drin stehen, und ein Cluster ist >4096 Byte groß, dann hat die Datei für das FS eine größe von 4096 Byte, Ja. >auch dann, wenn wie in dem Beispiel 4000 Byte gar nicht belegt sind. Ein >Cluster ist die kleinste einheit die von einem FS verwaltet werden kann. >Ansonsten stehen alle Infos zu den Dateien in der FAT. Aber die echte, netto Dateigröße steht IMMER in der FILE_INFO Struktur, nicht cdie Bruttogröße!
Falk Brunner schrieb: > Aber die echte, netto Dateigröße steht IMMER in der FILE_INFO Struktur Das ist halt die Frage, was man dafür hält. Die Datei selbst ist heute immer auf ein Byte genau angegeben (das war zu Zeiten von CP/M mal anders), aber der tatsächlich belegte Speicherplatz wird in Clustern vergeben. Kann man auch so sehen, dass die Dateien nicht direkt aufeinanderfolgen, sondern dass eine neue Datei erst an der nächsten Clustergrenze anfängt. Die Folge ist, dass eine Datei mit z.B. 5267 Bytes insgesamt 8 kByte belegt. Darum muss man sich normalerweise nicht kümmern, es sei denn man wundert sich, dass nicht so viel auf die Platte draufgeht wie man sich ausgerechnet hat. Im Durchschnitt sind alle Dateien um 1/2 Cluster grösser, was Windows auch ausweist (Grösse auf dem Datenträger). Das ist besonders ungünstig bei vielen kleinen Dateien. Georg
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.