AllmysteryNavigation
Menschen Wissenschaft Politik Mystery Kriminalfälle Spiritualität Verschwörungen Technologie Ufologie Natur Umfragen Unterhaltung
weitere Rubriken
PhilosophieTräumeOrteEsoterikLiteraturAstronomieHelpdeskGruppenGamingFilmeMusikClashVerbesserungenAllmysteryEnglish
Diskussions-Übersichten
BesuchtTeilgenommenAlleNeueGeschlossenLesenswertSchlüsselwörter
Schiebe oft benutzte Tabs in die Navigationsleiste (zurücksetzen).

SD-Karte Filesystem Block/Cluster-Versuche

66 Beiträge ▪ Schlüsselwörter: Kris Kremers, Lisanne Froon, SX270 HS ▪ Abonnieren: Feed E-Mail
cyclic Diskussionsleiter
Profil von cyclic
beschäftigt
dabei seit 2019

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

27.06.2025 um 09:58
Zitat von scepticalsceptical schrieb:Unter welchen Bedingungen eine Lücke geschlossen wird, kann von ganz vielen Faktoren abhängig sein.
Ich habe da inzwischen umfangreiche Tests gemacht und es ist tatsächlich überhaupt nicht komplex: es wird immer mit dem ersten freien Cluster (kleinste Adresse) begonnen und dann aufsteigend gefüllt. Auch wenn eine Lücke nur 1 Cluster groß ist wird sie genutzt und auch habe ich normalgroße JPGs über 10 Lücken fragemtieren lassen. (wir reden hier inmer nur von der logischen FAT-Ebene nicht von NAND-Pages / -Blöcken / etc. an die man eh nicht rankommt).

Probier es selbst mal aus (geht prima auch ohne Kamera).

Warum das mit der gleichen Clusteranzahl dann stimmt merkst du dann selber.
Zitat von scepticalsceptical schrieb:Steht irgendwo im Bericht, wie viele wiederhergestellte Bilder überhaupt noch einen Gelöscht-Eintrag hatten ?
Ich weiß da auch nicht mehr. Nichtmal dass es bei den 64+4 oder 24+4 um 0xE5-Verzeichniseibträge geht steht irgendwo. Es ist nur bisher die einzig sinnvolle Annahme, die ich kenne. Aber die Erkenntnis, dass diese erhalten bleiben, wenn das Verzeichnis(Cluster) nicht mehr angefasst wird, dürfte der Schlüssel zum Verständnis sein (immerhin gibt es noch 63 oder 103 weitere fehlende Dateien, die wahrscheinlich nur durch die fehlenden Nummern belegbar sind.


melden

SD-Karte Filesystem Block/Cluster-Versuche

28.06.2025 um 11:13
Dateien ohne diese Einträge bezeichnet man als verlorene Dateien. Das könnten dann Dateien von vor einer Formatierung sein. Sowas würde ich hier dann eher weiter hinten im Datenbereich erwarten.

Hast du dir das mit den TMP-Dateien schon angeschaut. Erzeugt die Kamera solche Dateien - die übrigens insofern interessant sind, weil sie eigentlich noch einen zusätzlichen VFAT-Eintrag brauchen. Es ist auch nicht klar, wo die Einträge der neuen Bilder sind oder wo die neuen Bilder abgespeichert sind.


1x zitiertmelden
cyclic Diskussionsleiter
Profil von cyclic
beschäftigt
dabei seit 2019

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

28.06.2025 um 19:44
Zitat von scepticalsceptical schrieb:Hast du dir das mit den TMP-Dateien schon angeschaut. Erzeugt die Kamera solche Dateien
Beitrag von cyclic (Seite 2)

Ja sowohl ich und vorher schon @Offshore7 haben experimentiert. Nein die Kamera erzeugt solche Dateinamen nicht. Wohl aber mind. 2 Windows-Standard-Bildbetrachter u.a. der Viewer, der auch in den EXIF-Daten div. Bilder auftaucht. Und zwar z.B. beim Drehen. Das waren höchstwahrscheinlich die Ermittler in Panama.

Unklar ist wie viele Bilder gedreht wurden (wie viele TMP-Dateien es gibt) und ob diese zu den gelöschten gehören. Mir schien, dass die unter bestimmten, aber unklaren, Umständen erst beim Schließen des Viewers gelöscht werden, so dass sie evtl. erhalten bleiben, wenn man vorher die SD-Karte aus dem Reader reißt - z.B. weil man merkt, dass man gerade großen Mist baut (reproduzieren könnte ich das aber nicht mehr).

Jedenfalls benennen beide Viewer die Datei in eine TMP um und dann direkt vor dem Löschen scheinbar nochmal in eine tmp (kleines tmp). Merkwürdig ist, dass man bei IP nur die TMP-Form sieht. Spricht für mich dafür, dass die TMP nicht gelöscht wurden.

Irgendeine Idee, welches Tool in einem Schwung 40 Thumbnails erzeugt, aber nicht mehr? Linux Gnome Nautilus File-Explorer (ggf. entspr. alte Version) könnte ein Kandidat sein, konnte ich aber noch nicht testen


melden

SD-Karte Filesystem Block/Cluster-Versuche

29.06.2025 um 22:25
Gibt es irgendwo informationen über die Bilder vor April, z.B. Aufnahmen mit konkreter Bildnummer? Weiss man, welche Bildnummer das erste Bild trägt?


1x zitiertmelden
cyclic Diskussionsleiter
Profil von cyclic
beschäftigt
dabei seit 2019

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

29.06.2025 um 22:52
Zitat von scepticalsceptical schrieb:Gibt es irgendwo informationen über die Bilder vor April, z.B. Aufnahmen mit konkreter Bildnummer? Weiss man, welche Bildnummer das erste Bild trägt?
Die Bilder (in schlechter Auflösung), die es halt gibt sind alle auf Koudekaas (wie immer). Wobei Christian (Doctective) neulich Zweifel angemeldet hat, ob das wirklich Bilder der SX270 sind.

Das erste Bild der Reise soll lt. Scarlet (Koudekaas) #167 sein. Welche Nummer das erste überhaupt erhaltene Bild hat ist unbekannt. Auch ob es vor #167 überhaupt Bilder auf der SD-Karte gibt. Der Januar-Ordner 100___01 kann theoretisch leer sein, wenn man alle Dateien darin von einem Rechner gelöscht (wegge-moved) hat.

Es gibt ganz wenige April-Bilder mit weitgehend vollständigen EXIFs (ich kenne genau zwei), aber ich kenne keine vom März mit Canon-spezifischen EXIF-Daten. IP hat offenbar Original-EXIFs aller Nachtbilder erhalten (so konnten sie die Temperatur auslesen).


melden
cyclic Diskussionsleiter
Profil von cyclic
beschäftigt
dabei seit 2019

Profil anzeigen
Private Nachricht
Link kopieren
Lesezeichen setzen

SD-Karte Filesystem Block/Cluster-Versuche

11.07.2025 um 09:22
Etc:
  • CTG-Dateien "faken":
    Wenn man die SD-Karte formatiert und vom PC die Ordnerstruktur DCIM/<FolderNr>___<Monat>/ erzeugt und Bilder in die Ordner kopiert und dann die SD-Karte in die Kamera einlegt und einmal einschaltet (zumindest via View-Mode), dann wird der Unterordner DCIM/CANONMSC/ angelegt und für alle Monatsordner werden CTG-Catalog-Dateien erzeugt (M<OrdnerNumer4Stellig>.CTG z.B. M0124.CTG) - d.h. auch wenn man kein einziges Bild aus einem bestimmten Monatsordner betrachtet hat.
    ==> Man muss also keine CTG-Dateien faken, man muss nur einmal die SD-Karte in die Kamera einlegen.

  • Video-Größen / Belegungs-Plausibilitäts-Check:
    Bis einschließlich #508 existieren lt. IP 370 Bilder und 7 Videos. #508 endet in Sektor 336859 (Clusterende), d.h. bei Byte 1724907519. Das sind 1645 MiB. Bei durchschnittlich 3.7 MiB / Bild bleiben 276 MiB für die 7 Videos, also 40 MiB / Video. Das dürften etwa 13s Länge je Video sein (10s => 31 MiB)

  • Löschen ganzer Ordner am PC:
    • Nach Löschung des Ordners 124___06 sind Verzeichniseinträge noch als [0xE5]24___06 und alle enthaltenen Dateien noch als [0xE5]MG_<Nr>.JPG erhalten (Bilder sind wiederherstellbar)
    • Nach einer weiteren Aufnahme mit der Kamera, sind die Verzeichniseinträge des Ordners und der enthaltenen Bilder nicht mehr auffindbar (ImHex Search). Bilder sind noch widerherstellbar soweit Content noch nicht überschrieben (DMDE) - in dem Fall ist eines bereits überschrieben.

  • Datei- und Ordner-Nummerierung:
    Es existierte ein einziger Ordner 125___07 mit einem Bild IMG_3125.JPG, obwohl das Kameradatum korrekt auf Juli eingestellt ist, landete das nächste Bild in 128___07 und das Bild heißt IMG_0143.JPG.
    ==> Es wurde weder die Ordnernummer zurückgesetzt, noch der existierende Juli-Ordner genutzt (obwohl letzter / einziger Ordner) und auch der Bildzähler wurde nicht an die größte existierende Bildnummer angepasst (vermutlich weil in anderem Ordner). Das muss von früheren Ergebnissen abgegrenzt werden, wo ein Ordner weiterbenutzt wurde wenn man das Jahr ändert (aber gleicher Monat) und die Bildnummer entspr. dem existierenden Bild mit der größten Nummer erhöht wird (aber das Bild im gleichen Ordner liegt).



melden