SD-Karte Filesystem Block/Cluster-Versuche

cyclic schrieb am 05.07.2026:Aber dein Screenshot zeigt Verzeichniseinträge wo das erste Byte anzeigt dass du Bild 24 und 27 gelöscht hast (während 25 und 26 noch da sind).
Den Inhalt der CTG-Katalogdateien kann man nicht lesen. Es scheint nirgends einen freien Parser dafür zu geben (es scheint mehrfach die Bildnummer darin aufzutauchen aber das war's dann auch). D.h. du kannst nur anhand der Dateigröße der CTG erkennen wieviele Bilder sie umfasst.

Du hast insofern Recht, dass in der Datei selbst nur noch 2 Einträge da sind, aber wenn du dir den Screen-Shot des Sektors von der Katalogdatei nochmal genau anschaust siehst du, dass dort immer noch 4 Einträge im Sektor stehen. Hier tauchen eindeutig Einträge aus vorherigen Versionen der Katalogdatei im RAM-Slack auf.

Der folgende Screen-Shot zeigt den Anfang der 4 Einträge im Sektor, die rote Markierung ist das Dateiende:

@sceptical

Aha, gut dann war mir bisher einfach nicht klar was du meintest. Jetzt habe ich es dann hoffentlich gerafft.

Seltsam ist das weil der Sektor ja immer komplett neu geschrieben werden sollte. Es kann also keine Überbleibsel im letzten Sektor geben nur weil die Datei kürzer geworden ist (auch wenn es logisch klingt).

Wenn das so ist, dann könnte es auch tatsächlich bzgl. #509 relevant sein. Zumindest dann wenn #509 auf der Kamera gelöscht wurde und danach nicht nochmal in den Viewer-Mode gewechselt wurde (was gut möglich ist). In dem Fall wären dann "Reste" der um #509 geschrumpften CTG im RAM-Slack.

Werde ich versuchen nachzumachen...

cyclic schrieb:Seltsam ist das weil der Sektor ja immer komplett neu geschrieben werden sollte. Es kann also keine Überbleibsel im letzten Sektor geben nur weil die Datei kürzer geworden ist (auch wenn es logisch klingt).

Der Sektor wird auch eigentlich komplett neu auf den Datenträger geschrieben. Auch das müssten dann eigentlich Reste der Liste sein, die schon im Speicherpuffer der Software entstehen.

cyclic schrieb:Wenn das so ist, dann könnte es auch tatsächlich bzgl. #509 relevant sein. Zumindest dann wenn #509 auf der Kamera gelöscht wurde und danach nicht nochmal in den Viewer-Mode gewechselt wurde (was gut möglich ist). In dem Fall wären dann "Reste" der um #509 geschrumpften CTG im RAM-Slack.

Da habe ich wenig Hoffnung, wenn man bedenkt, dass die Behörden in Panama die Kamera ja auch nachträglich noch hatten und auch die Finder selbst. Da wird bestimmt jemand die Kamera eingeschaltet und sich die Bilder im Viewer-Modus angeschaut haben.

Ich habe den Test auch nochmal wiederholt, wobei nur die letzte Datei gelöscht wurde. Der letzte Eintrag in der Datei und der darauffolgende einzelne Eintrag im RAM-Slack waren erwartungsgemäß identisch. Es sieht also tatsächlich so aus, als ob die Software sektorweise in den Speicher liest, die Einträge in einer Datenstruktur verwaltet und wenn ein Bild gelöscht wird den Eintrag aus der Liste entfernt und die jetzt kürzere Liste in den Speicher schreibt, wobei der Speicherbereich vorher nicht initalisiert wird. Dann landen die Sektoren mit RAM-Slack wieder auf der Karte.

Sobald ein neues Bild aufgenommen wurde und man in den Viewer-Modus wechselt, ist dieser Resteintrag aber leider wieder weg. Die Sache mit dem Pattern im RAM-Slack der Bilder finde ich tatsächlich vielversprechender. Hast du schonmal nachgeschaut, ob sich dieses Pattern (falls genügend Bytes da sind) irgendwo in den Bilddaten wiederfindet?

sceptical schrieb:Da habe ich wenig Hoffnung, wenn man bedenkt, dass die Behörden in Panama die Kamera ja auch nachträglich noch hatten und auch die Finder selbst. Da wird bestimmt jemand die Kamera eingeschaltet und sich die Bilder im Viewer-Modus angeschaut haben.

Wenn das noch ging. Bei der Kamera soll immerhin Wasser im SD-Karten-/Batteriefach gewesen sein (und damit wahrscheinlich auch überall sonst, denn das ist gegen den Rest der Innereien nicht abgedichtet, soweit ich das erkennen konnte).

Auch ist auf den Fotos, die den ganzen Rucksackinhalt zeigen, die SD-Karte zu sehen, also nicht in der Kamera (es ist glaube ich nicht mal wirklich klar, ob sie in oder außerhalb der Kamera gefunden wurde). Anders als bei den Handys glaube ich dass die Kamera eher nicht nochmal eingeschaltet wurde.

sceptical schrieb:Hast du schonmal nachgeschaut, ob sich dieses Pattern (falls genügend Bytes da sind) irgendwo in den Bilddaten wiederfindet?

Ja, aber das war nicht der Fall. Der Teil der bei mir mehrfach ganz am Ende auftauchte (hinter einem FF D9) kommt so auch irgendwo im EXIF-Teil einer Bilddatei vor. Ich vermute dass die Kamera evtl. beim Einschalten ein Bild in ihrem Speicher generiert. Was ich noch testen wollte ist, ob das RAM-Slack-Pattern irgendwie speziell aussieht, wenn man die Kamera z.B. im Stockdunklen einschaltet.

cyclic schrieb:Ja, aber das war nicht der Fall. Der Teil der bei mir mehrfach ganz am Ende auftauchte (hinter einem FF D9) kommt so auch irgendwo im EXIF-Teil einer Bilddatei vor. Ich vermute dass die Kamera evtl. beim Einschalten ein Bild in ihrem Speicher generiert. Was ich noch testen wollte ist, ob das RAM-Slack-Pattern irgendwie speziell aussieht, wenn man die Kamera z.B. im Stockdunklen einschaltet.

So, jetzt wird es richtig interessant. Bei mir verhält sich die Kamera scheinbar etwas anders. Habe heute den Slack-Befehl mal etwas modifiziert. Er zeigt jetzt als ersten Sektor den mit Dateiende (RAM-Slack) an, wobei das letzte Byte der Datei anhand der Größenangabe speziell mit # markiert wird. Nach Formatierung und Aufnahme mehrere Bilder sieht der RAM-Slack der ersten 3 Bilder wie folgt aus:







Bei mir bleiben eindeutig Inhalte der vorherigen Dateien übrig. Bei Bild img_0045.jpg folgen hinter dem Dateieende (Offset 105) das Dateiende von img_0044.jpg bis Offset 478 und danach noch ein paar Bytes bis Offset 482 des Dateiendes von img_0043.jpg.

Geprüft mit ADE, hier der Beweis:

Original anzeigen (0,6 MB)

Die Sektoren stimmen überein.

@sceptical

Wenn ich das nicht wieder falsch verstehe entspricht das dem was ich auch beobachtet habe. Vielleicht ist es in meiner Beschreibung nicht klar genug geworden. Der letzte Sektor der letzten Aufnahme überschreibt das Pattern eben bis zu dem Byte an dem die vorige Datei endete. Wenn eine Datei zufällig alle 512 B des letzten Sektors füllt bleibt von dem ursprünglichen Pattern nichts übrig. Die Frage ist woher kommt das ursprüngliche Pattern von dem man im allergünstigsten Fall 511 B bei der ersten Aufnahme sehen kann? Aber ich bin mir sicher dass das von der Kamera generierte Daten sind und keine Dateireste von vor der Formatierung.

Das mit den CTGs habe ich mir noch nicht angeschaut (es ist schon wieder brütend heiß hier).

cyclic schrieb:Wenn ich das nicht wieder falsch verstehe entspricht das dem was ich auch beobachtet habe. Vielleicht ist es in meiner Beschreibung nicht klar genug geworden. Der letzte Sektor der letzten Aufnahme überschreibt das Pattern eben bis zu dem Byte an dem die vorige Datei endete. Wenn eine Datei zufällig alle 512 B des letzten Sektors füllt bleibt von dem ursprünglichen Pattern nichts übrig. Die Frage ist woher kommt das ursprüngliche Pattern von dem man im allergünstigsten Fall 511 B bei der ersten Aufnahme sehen kann? Aber ich bin mir sicher dass das von der Kamera generierte Daten sind und keine Dateireste von vor der Formatierung.

Das Pattern ist die eine Sache, aber die Bildreste könnten tatsächlich auch weiterhelfen. Ich hatte dich da wahrscheinlich falsch verstanden.

Ach du meine Güte, jetzt erst begreife ich worauf du die ganze Zeit hinaus willst! Und du hast völlig Recht - ich habe nur die ganze Zeit an was anderes gedacht.

Im letzten Sektor von #510 (und folgenden) könnte, mit etwas Glück, ein Rest von #509 stehen. Und da man alle anderen Dateien ja hat (wenn man einen Abzug der SD-Karte hat) könnte man das sogar ziemlich sicher feststellen, ob es ein Rest von #509 sein muss.

Voraussetzungen:
1) Nur wenn die Kamera zw. #509 und #510 nicht ausgeschaltet wurde
2) Nur wenn #510 RAM-Slack hat der lang genug ist
3) Und wenn #509 mehr von seinem letzten Sektor gefüllt hat als #510

Aber die Chance wäre schon absolut gegeben. Schade dass wir die Dateigröße von #510 nur auf ganze Cluster aufgerundet kennen.

Umgekehrt, wenn man im RAM-Slack von #510 jetzt das Ende einer früheren Datei wie z.B. #508 oder früher fände, aber keine unbekannte Datei (#509) dann kann das auch daran liegen, dass #509 einfach weniger vom letzten Sektor als #510 gefüllt hat. Die Wahrscheinlichkeit dafür hängt davon ab wie groß #510 exakt ist (was wir halt auch schon nicht wissen).

Sollten wir widererwarten einen Abzug der SD-Karte in die Finger bekommen, absolut ein Prüfpunkt.

Ich habe noch etwas sehr merkwürdiges gefunden, von dem bislang noch nicht die Rede war. Deswegen hatte ich auch hier erst an einen Fehler im Programm gedacht. Inzwischen habe ich es aber ebenfalls mit ADE positiv nachgeprüft.

Bei einzelnen Dateien zerlegt meine Kamera die Datei völlig ohne Grund in 3 Fragmente, wobei das mittlere Fragment plötzlich ganz am Ende des Datenbereichs gespeichert wird:



120753 ist hier tatsächlich der letzte Kluster im Volume. Ich habe jeweils die Inhalte der 3 Fragmente (erster Sektor) mit ADE gegengeprüft, es stimmt. Danach habe ich immer noch aus Unglauben die 3 Fragmente mit ADE in 3 Datein extrahiert und mit ImHex in eine Datei zusammengefügt, sodass am Ende gleich 2 andere Tools beteiligt waren. Tatsächlich kommt das richtige Bild dabei raus.

Hattest du das schonmal bei deinen Tests? Es wäre hier tatsächlich ebenfalls wichtig. Wenn sowas bei 509 passiert ist, dann war 509 von vornherein schon kleiner und es könnte doch noch ein Fragment irgendwo am Ende des Datenbereichs liegen. Ich weiß nicht, ob dieses Mittelfragment von PR gefunden würde, wenn die beiden anderen Fragmente (Anfang und Ende) überschrieben wurden.

@sceptical
Ähm, können das die drei eingebetteten Auflösungen sein (die jeweils in sich vollständige JPEGs darstellen)?
- Volle Auflösung 4000x3000
- Preview 1440x1080
- Thumbnail 600x400

@sceptical

Übrigens, ich habe es zwar noch nicht selbst nachvollzogen, aber was du bzgl CTGs beschrieben hast ist exakt dasselbe Verhalten wie bei den Bildern:

Wechsel in den Viewer-Mode -> CTG wird erzeugt oder upgedatet -> CTG ist letzte geschriebene Datei

Löschen mind. einer Datei -> CTG wird erneut geschrieben -> RAM-Slack enthält den "überstehenden" Rest des letzten Sektors der alten CTG

Ausnahme wäre wenn die CTG durch das Löschen um einen Sektor kürzer würde.

cyclic schrieb:Ähm, können das die drei eingebetteten Auflösungen sein (die jeweils in sich vollständige JPEGs darstellen)?

Ne, dass würde schon wegen der Auftteilung der Kluster nicht passen.

cyclic schrieb:Übrigens, ich habe es zwar noch nicht selbst nachvollzogen, aber was du bzgl CTGs beschrieben hast ist exakt dasselbe Verhalten wie bei den Bildern:

Genau, insofern wäre es auch nicht ungewöhnlich.

sceptical schrieb:Hattest du das schonmal bei deinen Tests?

Also ohne Grund nicht. Fragmentierung habe ich ausgiebig getestet, aber das hatte (fast, s.u.) immer den Grund dass es halt Lücken durch gelöschte Dateien gab. Da habe ich diverse Konstellationen mit mehreren getrennten Mini-Lücken erzeugt.

sceptical schrieb:Bei einzelnen Dateien zerlegt meine Kamera die Datei völlig ohne Grund in 3 Fragmente, wobei das mittlere Fragment plötzlich ganz am Ende des Datenbereichs gespeichert wird:

Das "mittlere" Segment ist das das logisch von der Bytefolge der Datei in der Mitte kommt, richtig? Gut das habe ich in der Form nicht geprüft. Da aber jede noch so kleine Lücke immer in aufsteigender Adress-Reihenfolge belegt wurde, gehe ich davon aus, dass das auch für die Reihenfolge innerhalb einer Datei gelten muss. Ich meine Dateien werden üblicherweise sequentiell geschrieben. Das Filesystem / der Controller weiß beim Beginn des Schreibens nicht wieviele Daten kommen.

sceptical schrieb:120753 ist hier tatsächlich der letzte Kluster im Volume.

Also das wäre mir aufgefallen. Wie gesagt es wurde ausnahmslos immer jeder freie Speicher in aufsteigender Adress-Reihenfolge genutzt.

Was ich gelegentlich gesehen habe ist sowas:

cyclic schrieb am 09.03.2025:Discontinuity

Was zu Fragmenten führt, die aber jeweils hintereinander lagen. Was das genau verursacht habe ich nicht genau ergründet. Meine Vermutung waren defekte Bereiche auf der SD-Karte.

Wenn ich mich richtig erinnere hat das Aufnehmen von Videos ebenfalls zu Fragmenten geführt (immer), die aber ebenso direkt hintereinander lagen.

sceptical schrieb:120753

Was mir dabei noch auffällt ist dass 120753 x 32768 = 3'956'834'304 relativ dicht an max. Wert einer uint_32 Variable liegt (2³² = 4'294'967'296) und über dem Darstellungsbereich einer signed int_32 liegt. Irgendein seltsames Adress-Umrechnungsproblem vielleicht? Ich erinnere mich dunkel, dass DMDE (neben div. weiteren) einen Bug hat, wodurch teilweise absurd große (gigabyte-große) Fragmente angezeigt werden (was natürlich falsch ist).

sceptical schrieb:Bei mir bleiben eindeutig Inhalte der vorherigen Dateien übrig. Bei Bild img_0045.jpg folgen hinter dem Dateieende (Offset 105) das Dateiende von img_0044.jpg bis Offset 478 und danach noch ein paar Bytes bis Offset 482 des Dateiendes von img_0043.jpg.

Hmm. Erstaunlich dass da Bufferreste übrig bleiben, obwohl Bild 0045 größer ist als 0043 und 0044. Was wäre im RAM-Slack 0045, wenn du die Kamera vor img_0045.jpg zunächst ausgeschaltet hättest? Also äquivalent zum Ausschalten vor #510 oder nach #508.

Offshore7 schrieb:Erstaunlich dass da Bufferreste übrig bleiben, obwohl Bild 0045 größer ist als 0043 und 0044.

Das ist was die Sache irgendwie skurril macht. Es hat den Anschein, dass es einen 512-Byte-Buffer gibt, der ausschließlich für den jeweils letzten Sektor jeder Datei genutzt wird, egal wie groß die Datei ist. Keine Ahnung welchen technischen Sinn das hat.

Offshore7 schrieb:Hmm. Erstaunlich dass da Bufferreste übrig bleiben, obwohl Bild 0045 größer ist als 0043 und 0044.

Das wirkt auf mich tatsächlich auch so, als gäbe es einen einzelnen Sektor, der speziell für das Schreiben des Dateiendes da ist. Da spielt dann die Gesamtgröße keine Rolle.

Offshore7 schrieb:Was wäre im RAM-Slack 0045, wenn du die Kamera vor img_0045.jpg zunächst ausgeschaltet hättest?

Wie @cyclic auch schon getestet hat, wäre da wohl nur das Pattern drin. Bei Einschalten der Kamera wird der Sektor hier scheinbar mit diesem Pattern gefüllt. Danach werden bis zum nächsten Ausschalten die Dateienden der folgenden Bilder drübergeschrieben.

Man könnte das Pattern und die Dateienden tatsächlich schön nutzen, um die Plausibilität der Bildreihenfolge zu testen.

cyclic schrieb:Was mir dabei noch auffällt ist dass 120753 x 32768 = 3'956'834'304 relativ dicht an max. Wert einer uint_32 Variable liegt (2³² = 4'294'967'296) und über dem Darstellungsbereich einer signed int_32 liegt. Irgendein seltsames Adress-Umrechnungsproblem vielleicht?

Keine Ahnung, wo hier das Problem liegt, bei den USB-Sticks passiert es nicht und die haben noch mehr Speicher. Es wird aber noch seltsamer. Nach ein paar Tests ist das hier sogar von der konkreten Klusternummer abhängig. Er schreibt immer bis Kluster 129, springt dann aus unerfindlichen Gründen immer zum Kluster 120706, schreibt von dort bis zum Ende des Datenbereichs und springt wieder zurück zu Kluster 130. Ich muss mal den Akku laden und ganz viele Bilder aufnehmen. Eventuell passiert es noch bei anderen Kluster-Nummern.

@sceptical
Ich glaube dir dass das bei dir so ist. Ich habe etwas in der Art aber selbst nie gesehen und bei meinen Fragmentierungstests (Auswertung mit Filefrag + Octave) hätte ich das gesehen. Auch meine wirklich normal genutzte SD-Karte in der S120 hat sowas nie produziert (dürfte SW-mäßig praktisch identisch mit der SX270 sein). Vielleicht spinnt deine SD-Karte auch irgendwie.

BTW: Was man auch noch testen müsste ist, ob ein aufgrund Fehler nicht geschriebenes Bild trotzdem das End-Sektor-Pattern verändert (das muss nicht, aber könnte durchaus sein).

cyclic schrieb:Ich glaube dir dass das bei dir so ist. Ich habe etwas in der Art aber selbst nie gesehen und bei meinen Fragmentierungstests (Auswertung mit Filefrag + Octave) hätte ich das gesehen. Auch meine wirklich normal genutzte SD-Karte in der S120 hat sowas nie produziert

Hast du die SD-Karte bei dir schonmal mit Bilder von der Kamera komplett voll gehabt? Vielleicht tritt der Fehler bei dir erst bei einer sehr hohen Kluster-Nummer auf.