SD-Karte Filesystem Block/Cluster-Versuche

SX2070 HS auf 2GB SD-Karte:

Original:

Dateianhang: Original_2025-03-12.txt (18 KB)

Formatiert:
FILENAME START END M0239.CTG 280.. 280: <- catalog file probably create / updated when switching into the viewer mode IMG_2969.JPG 10.. 111: IMG_2970.JPG 112.. 202: IMG_2971.JPG 203.. 278: <- gap: 2 blocks - probably because the CFG file was created in viewer mode MVI_2972.MP4 281.. 537: 538.. 540: IMG_2973.JPG 541.. 625: IMG_2974.JPG 626.. 723: (IMG_2975.JPG 724.. 817: <- Before changing timestamps with exiftool - size: 94 blocks) IMG_2976.JPG 818.. 908: IMG_2977.JPG 909.. 992: MVI_2978.MP4 993.. 1271: 1272.. 1274: IMG_2979.JPG 1275.. 1355: IMG_2980.JPG 1356.. 1427: IMG_2981.JPG 1428.. 1520: (VIDEO 2982 DELETED BEFORE IMAGE 2983) <- gap: 260 blocks! IMG_2983.JPG 1781.. 1883: IMG_2984.JPG 1521.. 1608: <- filled in gap between 2981 and 2983 (IMAGE 2985 DELETED BEFORE IMAGE 2986) <- gap: 62 blocks (was <- filled in gap between 2981 and 2983) IMG_2986.JPG 1671.. 1772: <- filled in gap between 2981 and 2983 IMG_2987.JPG 1609.. 1670: <- filled in gap between 2981 and 2983 1773.. 1780: <- filled in gap between 2981 and 2983 (+Discontinuity in 1774) 1884.. 1884: <- next free after 2983 IMAGE 2988 DELETED BEFORE IMAGE 2989 (SHUTTING CAM DOWN BEFORE 2989) <- no gap IMG_2989.JPG 1885.. 1953: IMG_2990.JPG 1954.. 2015: IMG_2991.JPG 2016.. 2079: IMAGE 2992 DELETED BEFORE IMAGE 2993 (SHUTTING CAM DOWN BEFORE 2993) <- no gap IMG_2993.JPG 2080.. 2140: IMG_2994.JPG 2141.. 2192: IMG_2995.JPG 2193.. 2301: VIDEO 2996 DELETED BEFORE IMAGE 2997 (SHUTTING CAM DOWN BEFORE 2997) <- no gap IMG_2997.JPG 2302.. 2387: IMG_2998.JPG 2388.. 2494: IMG_2975.JPG 2495.. 2588: <- After changing timestamps with exiftool (still 94 blocks) MVI_2999.MP4 2870.. 2872: 2589.. 2869: <- gap: 3 blocks IMG_3000.JPG 2873.. 2901: <- small 28 blocks image (mostly black) that would easily fit in every gap IMG_3001.JPG 2902.. 3000: IMAGES 3002, 3003, 3004 DELETED BEFORE 3005 (WITHOUT SHUTTING DOWN) <- gap 292 blocks (~3 images) IMG_3005.JPG 3293.. 3390: IMAGES 3006, 3007, 3008 DELETED BEFORE 3009 (SHUTTING CAM DOWN BEFORE 3009) IMG_3009.JPG 3001.. 3094: <- filled in the previous gap between 3001 and 3005 IMG_3010.JPG 3095.. 3188: <- filled in the previous gap between 3001 and 3005 IMG_3011.JPG 3189.. 3282: <- filled in the previous gap between 3001 and 3005 IMG_3012.JPG 3283.. 3292: <- filled in the previous gap between 3001 and 3005 (first part) 3391.. 3474: <- second part starts after 3005 IMG_3013.JPG 3475.. 3567: <- no gap IMAGES 3014, 3015, 3016, 3017 DELETED BEFORE 30018 (WITHOUT SHUTTING DOWN) IMG_3018.JPG 3927.. 4005: <- gap 359 blocks (~4 images) IMG_3019.JPG 4006.. 4083: <- no gap IMG_3020.JPG 4084.. 4163: <- no gap IMG_3021.JPG 4164.. 4238: <- no gap IMAGES 3022, 3023, 3024, 3025 DELETED BEFORE 3026 (SHUTTING CAM DOWN BEFORE 3026) IMG_3026.JPG 3568.. 3667: <- filled in the gap between 3013 and 3018 IMG_3027.JPG 3668.. 3765: <- filled in the gap between 3013 and 3018 IMG_3028.JPG 3766.. 3865: <- filled in the gap between 3013 and 3018 IMG_3029.JPG 3866.. 3926: <- filled in the gap between 3013 and 3018 (first part) 4239.. 4278: <- second part starts after 3021 SWICTHING OFF THE CAMERA ALWAYS -> no gaps IMG_3030.JPG 4279.. 4378: IMG_3033.JPG 4379.. 4485: IMG_3034.JPG 4486.. 4591: IMG_3035.JPG 4592.. 4705: IMG_3039.JPG 4706.. 4815: IMG_3040.JPG 4816.. 4923: IMG_3041.JPG 4924.. 5037: CREATING GAPS (NOT SWITCHING OFF THE CAM), THEN SWITCHING OFF AND TAKE PHOTOS TO SEE IF GAPS ARE FILLED -> yes (but no older gaps) IMG_3042.JPG 5038.. 5144: IMAGE 3044 DELETED (NOT SHUTTING DOWN) <- gap 74 blocks IMG_3044.JPG 5219.. 5324: IMAGES 3045, 3046 DELETED (NOT SHUTTING DOWN) <- gap 142 blocks IMG_3047.JPG 5467.. 5560: IMAGES 3048, 3049, 3050 DELETED (NOT SHUTTING DOWN) <- gap 220 blocks IMG_3051.JPG 5781.. 5876: IMAGES 3052, 3053, 3054, 3055 DELETED (NOT SHUTTING DOWN) <- gap 300 blocks IMG_3056.JPG 6177.. 6275: NEXT IMAGES TAKEN AFTER CAMERA WAS SWITCHED OFF (i.e. gaps can be filled now) IMG_3057.JPG 5145.. 5218: <- filled in the gap between 3042 and 3044 (74 blocks) 5325.. 5375: <- filled in the gap between 3044 and 3047 (51 blocks, second part) IMG_3058.JPG 5376.. 5466: <- filled in the gap between 3044 and 3047 (91 blocks) 5561.. 5577: <- filled in the gap between 3047 and 3051 (17 blocks) IMG_3059.JPG 5578.. 5682: <- filled in the gap between 3047 and 3051 (115 blocks) IMG_3060.JPG 5683.. 5780: <- filled in the gap between 3047 and 3051 (98 blocks) 5877.. 5890: <- filled in the gap between 3051 and 3056 (14 blocks) IMAGES 3061, 3062 REMOVED <- gap 142 blocks CHECK IF GAPS ARE ALSO FILLED IF SEVERAL IMAGES ARE MADE -> yes IMG_3063.JPG 6033.. 6131: IMG_3064.JPG 6132.. 6176: 6276.. 6332: <- after 3056 (second part) IMG_3065.JPG 6333.. 6435: IMG_3066.JPG 6436.. 6539: IMG_3067.JPG 6540.. 6642: IMG_3068.JPG 6643.. 6756: IMG_3069.JPG 6757.. 6863: IMG_3070.JPG 6864.. 6978: IMG_3071.JPG 6979.. 7094: IMG_3072.JPG 7095.. 7211: IMG_3073.JPG 5891.. 5998: <- filled in the gap between 3051 and 3056 IMG_3074.JPG 5999.. 6032: <- filled in the gap between 3051 and 3056 7212.. 7283: <- after 3072 IMG_3075.JPG 7284.. 7389:

Formatierungshinweise/-hilfe:
Spoiler
Folgende Regexp ist hilfreich um den Output von filefrag -e -b32768 *.* > filefrag_out.txt zu formatieren:

File size of ((?:IMG|MVI)_\d{4}\.(?:JPG|MP4)) is \d+ \(\d+ blocks of 32768 bytes\)\n\s*ext: logical_offset: physical_offset: length: expected: flags:\n((?:\s*\d+:\s+\d+\.\.\s+\d+:\s+\d+\.\.\s+\d+:\s+\d+:\s+(?:\d+:\s+)?merged(?:\,eof)?\n)+)(?:IMG|MVI)_\d{4}\.(?:JPG|MP4): \d+ extents? found\n

Der Rest geht rel. einfach indem man die wenigen zusätzlichen Zeilen von "fragmentierten" Dateien von Hand einrückt und dann mit einem Editor mit Block-Selektions/Editier-Modus (z.B. Kate) die überflüssigen Spalten löscht.


Graph:



Matlab/Octave-Skript:

Dateianhang: Filefrag.m (9 KB)

Zum Vergleich S120 32GB SD-Karte:

Original:

Dateianhang: Original_S120.txt (1 KB)

Formatiert:
IMG_3083.JPG 284437.. 284488: 287151.. 287208: Discontinuity: Block 3328 is at 18377664 (was 18207296) 287340.. 287366: IMG_3084.JPG REMOVED BEFORE 3085 (WITHOUT SHUTTING CAM OFF) gap: 117 blocks IMG_3085.JPG 287474.. 287487: 287367.. 287472: Discontinuity: Block 896 is at 18391488 (was 18399232) 287488.. 287497: IMG_3086.JPG REMOVED BEFORE 3086 (SHUTTING CAM OFF AND ON) no gap IMG_3087.JPG 287498.. 287588: IMG_3088.JPG 287589.. 287628: (black img. 40 blocks - not filling gap)

Ergebnisse:

• Eine Lücke (in der Größe der gelöschten Datei) bleibt wenn man letztes Bild/Video löscht aber Kamera nicht ausschaltet
• Keine Lücke wenn man letztes Bild löscht und dann Kamera aus und wieder anschaltet (Voriges Bild und nächstes liegen "Sektor an Sektor")
• Lücken werden nicht gefüllt, obwohl nächstes Bild hineinpasst (selbst die rel. großen Lücken durch gelöschte Videos werden nicht gefüllt). Das muss sich eigentlich spätestens ändern wenn die SD-Karte sonst nicht mehr genug Platz hat, aber noch ausreichend Lücken frei sind.
  Bestehende Lücken werden gefüllt, selbst wenn kein einziges Bild komplett hineinpasst (Datei "fragmentiert").
  Anm.: Erst durch die grafische Ausgabe habe ich bemerkt, dass tatsächlich fast alle Lücken gefüllt wurden, was ich vorher übersehen hatte. Die einzige nicht wieder befüllte Lücke ist interessanter Weise durch die Änderungen der EXIF-Daten mit exiftool entstanden (Bild 2975). exiftool benennt die Original-Datei um (hier in IMG_2975.JPG_original). Diese Datei hatte ich übersehen - sie belegt unverändert den originalen Bereich. Es gibt also keinerlei unbelegte Lücken.
• Auch bei drei gelöschten Bildern bleibt die Lücke, wenn man direkt das nächste Bild macht ohne die Cam auszuschalten
• Mit Ausschalten passierte etwas merkwürdiges: das nächste Bild wurde in die zuvor entstandene drei Bild große Lücke gesetzt und liegt jetzt vor dem Bild früheren Bild (andere frühere, zT. deutlich größere Lücken wurden nicht genutz)

Anmerkungen:

• Auch wenn filefrag für SD-Karten wohl nur die logische Struktur wiedergeben kann, so scheint die dann aber doch nicht ganz so weit von der physikalischen Wirklichkeit entfernt zu sein - immerhin werden auch "Discontinuities" ausgegeben (wohl defekte Bereiche) und die entsprechend entstehenden Fragmente (das könnte die "logische Ebene" auch komplett verschleiern).
• Auch Mini-Lücken von nur einem Block/Cluster Länge werden gefüllt:
  
  Unten: vorher letzte Bild-Datei, Mitte: 1-Block-Datei deren 1-Block großer Vergänger gelöscht wurde, Oben neues Bild (1-Block-Lücke wird genutzt)
  Allerdings bleiben auf der SD-Karte genauso viele 1-Block-Lücken wie es CTG-Katalog-Dateien gibt (die jeweils auch einen Block lang sind).
  Vermutung: Beim Anlegen der Datei wird diese (bzw. evtl. zunächst eine Temp-Datei) so oft überschrieben/geändert, dass dieser Bereich wegen Wear-Leveling der SD-Karte später ungenutzt bleibt.
  

@cyclic

Denkbar, dass ein SD-Karten-Controller die durch Bild-Löschung eigentlich freigewordenen Cluster in der simulierten physikalischen Umgebung bis zur Neu-Initialisierung (Aus-/Einschalten) inkl. TRIM / Garbage Collection und Re-Mapping sperrt.

Würde allerdings deine Tests mit dem USB-SD-Kartenleser nicht erklären. Vllt. kannst du am Rechner mal ein fstrim an die SD-Karte senden, wenn die das mitmacht und du dich traust. :-)

@Offshore7

Ich habe ja noch einen anderen Verdacht bzgl. der Unterschiede zw. ausschalten und nicht ausschalten: Evtl. schließt die Kamera die File-Handles nicht - sprich die Software hat ein Resource-Leak, was dazu führen könnte dass das Löschen nicht abgeschlossen ist und der Bereich nicht freigegeben wird, bis man die Kamera ausschaltet.

Der andere Effekt, dass frühere Lücken nicht genutzt werden (auch nicht via Computer) könnte davon unabhängig sein. Allerdings hat er gerade eine Lücke doch befüllt, nachdem ich drei Bilder gelöscht habe (s. Protokolle der SX270 oben).

Das mit dem fstrim muss ich mir mal genauer ansehen, bevor ich das versuche.

cyclic schrieb:Evtl. schließt die Kamera die File-Handles nicht - sprich die Software hat ein Resource-Leak, was dazu führen könnte dass das Löschen nicht abgeschlossen ist

Auch eine gute und realistische Idee. Möglicherweise könntest du das forcieren, indem du dir nach dem Bildlöschen erst mal ein paar Fotos auf der Kamera anschaust und dann das nächste Foto machst.

Bekomme vermutl. am WE ne alte SD-Karte und hab noch nen alten Läppi mit SD-Kartenleser. Dann teste ich mal bissl. Ohne Kamera natürlich schwierig, aber ich denke, wir sind schon gut im komplizierten Thema. :Y:

Ob die 16GB SanDisk WL hatte oder nicht (ich denke schon) ist im Prinzip egal, würde ja trotzdem auf ein Controller- oder File-Handle-Problem hinauslaufen. Leider ist die Controller-Logik bei allen Herstellern top secret. :(

Jetzt werden auf einmal Lücken gefüllt, auch solche die so klein sind, dass das nächste Bild nur teilw. reinpasst ("fragmentiert"). Keinen blassen Dunst warum auf einmal. Die alten Lücken bleiben weiterhin frei. Am "Füllstand" sollte es nicht liegen, es sind gerade mal 10% der Karte belegt.

Protokolle sind upgedatet.

Wie auch immer, das könnte durchaus spannend sein, je nachdem wie detailliert die Infos in den Akten sind und ob wir die bekommen können.

cyclic schrieb:Auch wenn filefrag für SD-Karten wohl nur die logische Struktur wiedergeben kann

Liegt nicht an filefrag, da hast du mE schon mit das beste Tool gewählt. Liegt mE daran, dass das Auslesen der physikalischen Struktur bei WL unmöglich oder nur mit Spezialtools oder Spezial-Hardware des Herstellers möglich ist.

Hast du dir eigentlich ein Python-Script oder so gebastelt, um die filefrag-Ausgaben zu formatieren?

cyclic schrieb:Jetzt werden auf einmal Lücken gefüllt, auch solche die so klein sind, dass das nächste Bild nur teilw. reinpasst ("fragmentiert").

Das Blöde ist halt, dass der Controller gar nicht weiß, dass er ein FAT32-System mapped. KA inwieweit der da quasi auf Hilfe des Betriebssystems angewiesen ist. Sowas wie TRIM wäre so eine Hilfe, was in der SX270 sicher auch iwie implementiert ist.

cyclic schrieb:Wie auch immer, das könnte durchaus spannend sein, je nachdem wie detailliert die Infos in den Akten sind und ob wir die bekommen können.

@Doctective ist grad ziemlich busy, aber Zeit spielt ja keine Rolle. Letztlich ist es bei dem internationalen Bekanntheitsgrad des Falls eh erstaunlich genug, dass wir nach 10 oder 11 Jahren zu neuen Erkenntnissen kommen, ne.

Offshore7 schrieb:Hast du dir eigentlich ein Python-Script oder so gebastelt, um die filefrag-Ausgaben zu formatieren?

Zunächst nur wilde Regexps und Block-Editier-Mode in einem Texteditor (Kate), jetzt gerade ein Matlab/Octave-Skript fertig bekommen. Beides oben in Spoilern zu bewundern.

Dabei habe ich jetzt gemerkt, dass ich bzgl. Lückenfüllen wohl ziemliche Tomaten auf den Augen hatte. Tatsächlich wurden alle Lücken gefüllt (s. Graph oben), wenn man zu lange und zu oft auf diese textuelle Ausgabe starrt, sieht man irgendwann gar nichts mehr...

Offshore7 schrieb:Letztlich ist es bei dem internationalen Bekanntheitsgrad des Falls eh erstaunlich genug, dass wir nach 10 oder 11 Jahren zu neuen Erkenntnissen kommen, ne.

Viel von dem was gemacht wurde ist halt leider nur so halb ausgegoren. Selbst IP haben ein paar Fehlannahmen gemacht und manche Tests sind nicht so aussagekräftig wie sie hätten sein können (ihre Nachtfotos z.B.), obwohl es natürlich insgesamt absolut bemerkenswert ist, gerade was IP alles gemacht haben. Aber dass man noch das eine oder andere finden kann wundert mich nicht wirklich. Dass irgendwas davon den Fall löst glaube ich aber trotzdem nicht.

cyclic schrieb:Zunächst nur wilde Regexps und Block-Editier-Mode in einem Texteditor (Kate), jetzt gerade ein Matlab/Octave-Skript fertig bekommen. Beides oben in Spoilern zu bewundern.

Cool. Hab kein Tool gefunden, was meinen Ansprüchen entspricht, also Tabelle der Dateien inkl. Timestamps, Cluster- und Sektorgrenzen sowie grafische + chronologische Ausgabe.

Offshore7 schrieb:Cool. Hab kein Tool gefunden, was meinen Ansprüchen entspricht, also Tabelle der Dateien inkl. Timestamps, Cluster- und Sektorgrenzen sowie grafische + chronologische Ausgabe.

Hab das nochmal schöner gemacht. Nutzt jetzt auch eine andere Plot-Methode (schneller, funktioniert auch noch wenn ich 2500 Dateien von der SD-Karte meiner eigentlichen Kompaktkamera Anzeige).

Chronologische Anzeige der Dateien geht momentan über den Zählerwert im Dateinamen. Timestamps habe ich nicht drin. Die müsste man auch separat einlesen. Wozu wäre das wichtig? Könnte man sicher noch zusammen mit dem Dateinamen anzeigen. Was mit dem Ansatz so nicht geht, ist die Dateien auf der Y-Achse nach ihrem Zeitstempel zu positionieren (also so das Dateien mit ähnlichen Zeitstempeln näher beisammen sind). Das wäre eine ziemlich grundsätzliche Änderung und ich fürchte die Ausgabe würde sehr unübersichtlich.

Aber prinzipiell kann ich schon noch ein paar Verbesserungen einbauen...

cyclic schrieb:Aber prinzipiell kann ich schon noch ein paar Verbesserungen einbauen...

Nen QT-GUI-Tool .. :'D

cyclic schrieb:Chronologische Anzeige der Dateien geht momentan über den Zählerwert im Dateinamen. Timestamps habe ich nicht drin. Die müsste man auch separat einlesen. Wozu wäre das wichtig?

Nee, das wäre nur für eine chronologische Anzeige wichtig, aber die hast du ja drin. Die meisten Tools sehen so aus: Spoiler



Da erkennt man halt keine Chronologie der Dateien, also quasi nach Aufnahme- bzw. Speicherzeitpunkt.

Wir haben ja bislang nur spärliche Originalinfos: Spoiler
Cluster-Size hab ich jetzt mal 32kB genommen, wenn die Cam das so macht.




Ich frage mich, wie die Lücken 505, 506, 507 freigeblieben sein können?
- die gedrehten 506 und 507 landeten in früheren Lücken
- kein Nachtfoto wurde gedreht (nicht sehr plausibel)

Die früheren Lücken können nur durch frühere Drehungen entstanden sein, sonst wären die Lücken ja durch die Fotos vom 1.4. gefüllt worden. Oder alle Fotos vom 1.4. und 8.4. und die gedrehten Fotos landeten in der Lücke eines großen gelöschten Videos.

Im Zusammenhang mit gelöschten 64 Bildern und 4 Videos sowie 40 wiederhergestellten Bildern + Thumbnails ausschließlich zwischen #476 und #609 verursacht das bei mir etwas Brainfuck. :-)

Vllt. fällt dir ein plausibler Ablauf ein. Wie gesagt, leider sind die Infos sehr dünn. Aber es sieht zumindest so aus, dass die Lücken 505, 506, 507 nicht gefüllt wurden (zB mit "#507 gedreht" oder "#550 gedreht"). Außer Matt oder das NFI haben die neu gespeicherten gedrehten Bilder aus der Analyse rausgelassen, wo spätestens beim zweiten gedrehten Bild Lücken hätten gefüllt werden müssen.

Offshore7 schrieb:Da erkennt man halt keine Chronologie der Dateien, also quasi nach Aufnahme- bzw. Speicherzeitpunkt.

Ja das war natürlich oberste Prio, dass man das visuell halbwegs intuitiv verständlich erkennen kann.

Zu dem Rest:

Also wenn dieser beknackte Viewer völlig ungefragt Bilder dreht und #506-#507 gedreht hat, dann muss er auch andere Bilder vom 1.4. und auch vom 8.4. gedreht haben, da die alle im selben Unterordner liegen sollten und definitiv nicht alle im Querformat sind (alle Hochformat-Bilder sollten gedreht werden). Oder verstehe ich das falsch und der dreht nur Bilder die man wirklich aktiv angeschaut hat?

Ich hätte vermutet, der macht das mit allen Bildern im aktuellen Ordner. Jedenfalls wäre dann auch das Nicht-Befüllen der selbst geschaffenen Lücken plausibel:
1. dreht alle Bilder mit entspr. EXIF-Dreh-Metadaten
2. speichert alle diese Bilder
3. löscht erst danach alle Originale
Wenn das Ding das dagegen jeweils nur für das gerade ausgewählte Bild macht, fände ich das Freibleiben der Lücken auch eher schwer nachvollziehbar. Es sei denn vielleicht, wenn er das Löschen und Speichern erst verzögert machen würde.

Moment, es gibt außer diesen vier Videos auch noch 64 gelöschte Bilder, die man gefunden hat? Und das sind nicht die Originale von gedrehten Bildern?
Die vier Videos machen mir schon Bauchschmerzen. Wurden die Lücken gefüllt? Wenn nicht können die Videos erst nach den Nachtaufnahmen gelöscht worden sein (ich kann mir auch nicht vorstellen, dass die Kamera während der Nachtaufnahmen durchgängig eingeschaltet blieb - falls doch wäre es denkbar, dass die Löschung am Anfang der Nacht-Session stattfand, aber sicher nicht noch früher).

Und wenn die Lücken (Videos + diese 64 Bilder) doch gefüllt wurden, ist die große Frage, ob man trotzdem noch diese Dateien finden konnte. Blieben sie physikalisch erhalten, obwohl dieselben logischen Cluster überschrieben wurden? Ich bezweifle ein bisschen dass das Wear-Leveling wirklich schon beim zweiten Beschreiben greift und dass die logischen Cluster so wenig mit dem physikalischen zu tun haben. Immerhin zeigt filerfrag auch "Discontinuities" an. Aber da hoffe ich, dass du das noch testen kannst, mit diesem Forensik-Tool(?)

cyclic schrieb:Wenn das Ding das dagegen jeweils nur für das gerade ausgewählte Bild macht, fände ich das Freibleiben der Lücken auch eher schwer nachvollziehbar. Es sei denn vielleicht, wenn er das Löschen und Speichern erst verzögert machen würde.

Dazu ein kleiner Test:

Hab extra SX270-Bilder (3 davon mit "Orientation - Rotate 90 CW" in den EXIF-Daten) von flickr genommen, umbenannt und einzeln auf die frisch formatierte FAT32 Partition kopiert, damit die Cluster-Reihenfolge stimmt:

1. Versuch

So sieht das aus, wenn man den Viewer benutzt und alle Bilder anschaut. Es ändert sich nix an den Dateien:



Jetzt habe ich die 3 Bilder mittels "Drehen-Button" aktiv gedreht. Wie man sieht, wurde nur #505 (gedreht) und ans "Ende" gesetzt (weil gelöschtes #505 Original beim Drehen noch im Zugriff), #506 und #507 (beide gedreht) landeten aber in den Lücken der vom Viewer "heimlich" gelöschten Originale:



2. Versuch

Hier habe ich ein 100MB Video am Anfang simuliert:



Dann das "100 MB Video" gelöscht und danach die 3 Fotos gedreht. Dieses Ergebnis entspricht den uns bekannten Daten von IP:



Eine Überlegung wäre: Angenommen #475 war ein 2 Minuten Video (200 MB) vom Beginn des Trails (und #475 würde wie #509 fehlen), das nach den Nachtfotos gelöscht wurde. Dann wären die gedrehten Fotos clustermäßig vor #476 gelandet und hätten es zerstört.

Hat die Cam eigentlich eine Auto-Abschaltung oder könnte sie theoretisch auch ne Stunde oder länger in Betrieb / Standby sein (und so zB ein gelöschtes Video bis zum Ausschalten vor dem Überschreiben bewahren)?

cyclic schrieb:Moment, es gibt außer diesen vier Videos auch noch 64 gelöschte Bilder, die man gefunden hat? Und das sind nicht die Originale von gedrehten Bildern?

Ich verstehe es derzeit so: 40 der 64 Bilder konnten wiederhergestellt werden, davon 20 Originale und 20 Thumbnails. Ist natürlich frei spekuliert und würde 20 gedrehten Bildern entsprechen.

cyclic schrieb:Blieben sie physikalisch erhalten, obwohl dieselben logischen Cluster überschrieben wurden? Ich bezweifle ein bisschen dass das Wear-Leveling wirklich schon beim zweiten Beschreiben greift und dass die logischen Cluster so wenig mit dem physikalischen zu tun haben.

Under Investigation - Fortschritt 0% :D

Offshore7 schrieb:Hat die Cam eigentlich eine Auto-Abschaltung oder könnte sie theoretisch auch ne Stunde oder länger in Betrieb / Standby sein (und so zB ein gelöschtes Video bis zum Ausschalten vor dem Überschreiben bewahren)?

Ja die Kamera geht in der Werkseinstellung nach 1 min in einen Stromsparmodus. Dabei wird das Display abgeschaltet (das Objektiv bleibt ausgefahren - das ist anders als das was passiert, wenn man in den Ansichtsmodus geht, wo nach einer Minute das Objektiv einfährt, aber das Display an bleibt). Ich habe das gerade nochmal getestet: Die Lücke bleibt auch, wenn die Kamera nach dem Löschen des letzten Bilds in diesen Stromsparmodus verfallen ist (wenig überraschend wenn nur das Display aus geht).

Offshore7 schrieb:Eine Überlegung wäre: Angenommen #475 war ein 2 Minuten Video (200 MB) vom Beginn des Trails (und #475 würde wie #509 fehlen), das nach den Nachtfotos gelöscht wurde. Dann wären die gedrehten Fotos clustermäßig vor #476 gelandet und hätten es zerstört.

In deiner Tabelle (heute 14:13) steht doch aber, dass die gedrehten Bilder ab Cluster Ende #609 + 1 abgelegt wurden. Oder ist das nur eine Vermutung?

Laut gedacht:

1. Versuch vs. 2. Versuch:
Also drehen doch nur mit entspr. User-Aktion (lässt die Panamaer dann doch wieder etwas dümmer aussehen).
Und die drei Bilder müssen nicht zwangsläufig in die Lücke des jeweils vorher gedrehten gespeichert werden, weil sie in irgendeine frühere Lücke fallen können. Und wenn die groß genug ist kommen dann da auch alle drei gedrehten Versionen von #505-#507 wieder hintereinander zu liegen. Aber wenn sie nach #609 (original nicht gedreht?) liegen, dann müssten (Teile der) Nachtfotos (mind. #609) selbst in dieser Lücke liegen. Dann wäre das entweder eine verdammt große Lücke, damit 100 Nachtfotos reinpassen, oder die Lücke müsste irgendwann während der Nacht-Session durch Löschen entstanden sein. Eigentlich können es auch vier größere Lücken von den vier Videos sein... Ich kriege auch einen Knoten ins Hirn.

Wenn man die genaue Clusterbelegung der SD-Karte kennen würde, könnte man die Löschzeitpunkte der Videos wahrscheinlich rel. genau eingrenzen. Mir scheint das eher auf ein spätes Löschen unmittelbar vor oder noch während der Nachtfotos hinzudeuten. Aber wenn man nicht wenigstens weiß wie groß diese Videos waren... (die Lücken von 64 Bildern, oder sogar nur 24 reichen ja auf keinen Fall um 100 Nachtbilder aufzunehmen). Und eigentlich hätten entspr. Merkwürdigkeiten auch den Niederländern auffallen sollen (aber da ist mein Vertrauen auch nicht unbegrenzt).

cyclic schrieb:In deiner Tabelle (heute 14:13) steht doch aber, dass die gedrehten Bilder ab Cluster Ende #609 + 1 abgelegt wurden. Oder ist das nur eine Vermutung?

Das mit "609+1" ist nur exemplarisch, wie im Hauptthread erklärt. Ist also keine IP-Erkenntnis oder Bestandteil der Akte.

cyclic schrieb:Und die drei Bilder müssen nicht zwangsläufig in die Lücke des jeweils vorher gedrehten gespeichert werden, weil sie in irgendeine frühere Lücke fallen können.

Auch laut gedacht:
Kommt auf den Lösch-Zeitpunkt an, welcher die früheren Lücken produziert hat. Wurden die Videos am 31.3. oder 1.4. vor 11:18 Uhr gelöscht, wären #476 und weitere Fotos doch direkt in den Lücken gelandet und hätten sie max. bis #609 vollständig gefüllt. Für gedrehte Fotos blieb dann nix mehr übrig. Und wenn doch, dann wären die gedrehten Fotos in der Drehen-Lücke der Video-Lücke gelandet :-), weshalb #505-#507 (die gelöschten Originale) nicht mehr "Sektor an Sektor" angeordnet oder vorhanden wären, weil von gedrehten Fotos überschrieben. Das trifft eigentlich auf alle durch Drehen verursachten Lücken zu, die wären ja mit dem jeweils nächsten gedrehten Foto oder mehreren gedrehten Fotos sofort gefüllt worden.

Bisher fällt mir nix Plausible ein, außer dass eine große Lücke vor #476 erst nach den Nachtfotos durch Löschen produziert wurde. Oder dass die Cam frühere Lücken, trotz Ausschalten, nicht gefüllt hat, der Microsoft-Viewer dann aber schon. Sind denn auf deinen SD-Karten clustermäßig frühere Lücken vorhanden, wo die Cam keinen Bock mehr hat, diese zu füllen?

cyclic schrieb:Ich kriege auch einen Knoten ins Hirn.

:'D

cyclic schrieb:Wenn man die genaue Clusterbelegung der SD-Karte kennen würde, könnte man die Löschzeitpunkte der Videos wahrscheinlich rel. genau eingrenzen.

Das ist wohl wahr. Auch die Timestamps der Ordner und weitere Dinge.

Offshore7 schrieb:Das mit "609+1" ist nur exemplarisch, wie im Hauptthread erklärt. Ist also keine IP-Erkenntnis oder Bestandteil der Akte.

Ahja hatte mich schon gewundert. Mir ist ehrlich gesagt immer noch nicht ganz klar was jetzt genau die Info ist, die wirklich direkt in den Akten steh

Offshore7 schrieb:Bisher fällt mir nix Plausible ein, außer dass eine große Lücke vor #476 erst nach den Nachtfotos durch Löschen produziert wurde. Oder dass die Cam frühere Lücken, trotz Ausschalten, nicht gefüllt hat, der Microsoft-Viewer dann aber schon. Sind denn auf deinen SD-Karten clustermäßig frühere Lücken vorhanden, wo die Cam keinen Bock mehr hat, diese zu füllen?

Jein, auf der SD-Karte meiner S120 sind knapp 2500 Bilder und da sind ganz alte (sogar noch die allerersten) drauf, aber zwischendurch habe ich sowohl einzelne Fehlschüsse direkt auf der Kamera, als auch ganze Serien per Computer gelöscht und auf der Karte sind lt. filefrag auschließlich Lücken, die alle jeweils nur einen Cluster Länge haben und davon gibt es 81. Das sind offensichtlich Lücken die dadurch entstehen, dass die Kamera *.CTG Katalog-Dateien schreibt/umschreibt. Es gibt nämlich auch 81 CTG-Dateien, die auch jeweils einen Cluster einnehmen. Eine neue CTG-Datei wird monatlich (nur bei neuen Aufnahmen) zusammen mit einem neuen Fotounterordner angelegt.

Es scheint so, dass die Kamera diese Min-Lücken irgendwie blockiert (ich habe allerdings keine Ahnung wie). Evtl. kommt es daher, dass dort mehrfach geschrieben wird und dann das Wear-Leveling greift? (Das wäre eigentlich ein interessanter Test: Überschreibe dieselbe Datei mehrfach und prüfe dann ob der Bereich irgendwann nicht mehr benutzt wird -> Noted...)
jedenfalls werden unter normalen Umständen auch 1-Block-Lücken genutzt. Ich habe das mal mit zwei Mini-Dateien simuliert, von denen ich dann die erste gelöscht habe (am Rechner) und dann ein Foto mit der SX270 aufgenommen habe. Und da wird die 1-Block-Lücke der gelöschten Datei genutzt:


Unten: vorher letzte Bild-Datei, Mitte: 1-Block-Datei deren 1-Block großer Vergänger gelöscht wurde, Oben neues Bild (1-Block-Lücke wird genutzt)

Sonst gibt es keine Lücken. (Ich werde mein Skript mal noch um eine Lücken-Auswertung und -Anzeige erweitern).

Jedenfalls müsste am 1.4. eine CTG-Katalogdatei angelegt worden sein und wahrscheinlich auch bereits eine zusätzliche 1-Cluster-Lücke entstanden sein (auch das versuche ich noch zu testen). Dass das irgendeine Relevanz hat sehe ich aber bisher nicht.

cyclic schrieb:Es scheint so, dass die Kamera diese Min-Lücken irgendwie blockiert (ich habe allerdings keine Ahnung wie). Evtl. kommt es daher, dass dort mehrfach geschrieben wird und dann das Wear-Leveling greift? (Das wäre eigentlich ein interessanter Test: Überschreibe dieselbe Datei mehrfach und prüfe dann ob der Bereich irgendwann nicht mehr benutzt wird -> Noted...)

Wenn du permanent den logischen Sektor 3000 überschreibst, wird der WL-Controller die Daten physisch permanent woanders speichern und auf den logischen Sektor 3000 mappen. Iwann wird der logische Sektor 3000 als defekt markiert, weil eigentlich der physische Sektor 4000 defekt ist, der beim letzten Lesen Retries verursachte. Der Versuch, einen Bad Block an einer bestimmten Adresse zu produzieren, dürfte nicht funktionieren oder mit dem Tod der SD-Karte enden, insofern das WL seinen Job macht. :-)

Gerade die Sektoren der beiden FATs werden ja permanent beschrieben. Ohne WL wären die SD-Karten sofort kaputt, würde man darauf zB ein Betriebssystem installieren. In ner Kamera ist das eigentlich wenig problematisch, dennoch dürften alle SDHC+-Karten-Controller seit ~2006 irgendeine Form von WL implementiert haben.