SD-Karte Filesystem Block/Cluster-Versuche

cyclic schrieb:Das wäre spannend das mit dem vermutlichen Viewer zu machen, den die Panamaer verwendet haben.

Was beim MS-Viewer spezifisch ist, ist der Anhang im Dateinamen "~RFxxxxxx.TMP". Hab ich sonst bei keinem Tool beobachtet.

Du könntest dir Windows 7 Professional SP1 unter VirtualBox installieren. Key brauchste nicht. Der Viewer ist direkt aktiv, weil Windows-Bord-App. Mit USB-SD-Leser, WinHex und PhotoRec kannste dann in Win 7 nahe an der panamaischen Realität testen. Das ist im Moment mein Test-Setting.

Aber mach dir kein Stress, der NFI-Datennachschub stockt grad etwas. :-)

Offshore7 schrieb:Aber mach dir kein Stress, der NFI-Datennachschub stockt grad etwas. :-)

Ich habe auch noch einen alten Laptop mit Win7 (und Linux). Ewig nicht probiert, schon damals wollte das Teil nach einem verkorksten Update nicht mehr normal booten. Ich wollte das schon länger mal probieren, aber solange ich nicht weiß wonach ich eigentlich suche, ist die Motivation etwas gedämpft.

Manchmal muss sich ja nur mal selbst anschubsen. Ich hatte befürchtet, dass schon das Starten ein Problem werden könnte, aber siehe da: er läuft (bis auf das elend lange Booten von einer rotating Disc). Es dürfte keine Relevanz haben, aber der Laptop hat einen integrierten SD-Kartenleser (war damals auch nicht ganz so selten soweit ich mich erinnere). Den habe ich auch genutzt.

Zuerst habe ich mal die 4 Bilder, die ich mit Gwenview gedreht hatte, nochmal mit Win PhotoViewer gedreht. EXIF zeigt, dass meine Programm-Version (Microsoft Windows Photo Viewer 6.1.7600.16385) auch in den Original-Bildern auftaucht allerdings nur bei zwei Bildern.

Hier die EXIF-Daten für zwei meiner Bilder (3105 Original, 3110 mit PhotoViewer gedreht und gespeichert)

Dateianhang: PhotoViewerRotateExif2.csv (8 KB)

Ansonsten sehe ich auf die Schnelle nichts besonderes. Im Gegensatz zu Gwenview, das die meisten EXIF-Werte löscht erhält der Viewer fast alles, auch das was unter "MakerNotes" geführt wird.

Bzgl. Speicher-Belegung verhält sich das Teil wie Gwenview (0_*: Original, 1_*: nach Drehen mit Gwenview, 2_*: nach dem Drehen der Bilder mit PhotoViewer):



D.h. die Bilder sind zurück in ihre alte Lücke gewandert (weil die ja nun frei war), und wieder hintereinanderweg abgelegt worden (keine Lücken wie bei Gimp).
Nun könnte es immer noch sein, dass der erste freie Bereich genutzt wird, dass also das zweite Bild in die Lücke des ersten wandert, wenn das erste Bild vorwärts gewandert ist. Also dieselben Bilder nochmal gedreht (3_*). Auch da selbes Verhalten wie Gwenview: Bilder hintereinanderweg nach hinten gewandert (erste Lücke wird nicht genutzt). Das scheint mir aber generell das Verhalten der SD-Karte zu sein: es wird nicht wieder zurückgesprungen bevor das Teil nicht neu "gebootet" wurde.

Bedeutet: Wenn alle Bilder in einer Session gedreht wurden ist es plausibel, dass alle Original-Bereiche nicht überschrieben wurden und so die Thumbnails mittels entspr. Forensik-SW auffindbar waren. Es ist nicht notwendig eine größere Lücke (z.B. durch ein gelöschtes Video) anzunehmen, in die die gedrehten Versionen verschoben wurden.

Genauere Speicheranalyse habe ich jetzt aber noch nicht durchgeführt (nur wieder mit filefrag, wie bisher immer)

cyclic schrieb:Das scheint mir aber generell das Verhalten der SD-Karte zu sein: es wird nicht wieder zurückgesprungen bevor das Teil nicht neu "gebootet" wurde.

...was ich für das oder zumindest einen Teil des Wear-Levelings halte. Prozesse, die häufig (Temp-)Dateien schreiben und wieder löschen, beschreiben so nicht ständig dieselben Bereiche. Erst nach einem "Reboot" der Karte fängt sie wieder bei der ersten freien Lücke an (Winz-Lücken scheinen dabei ignoriert zu werden).