[German] proaktive Erkennung und Rückmeldung korrupte / unlesbare files

[spiff]

Hallo,

meine Datenbankanalyse läuft immer ohne Fehler durch, trotzdem habe ich vier nicht mehr lesbare files in der DB. Das habe ich durch Zufall entdeckt, natürlich erst nach längerer Zeit und somit sind auch meine Fesplatten backups überschrieben mit den korrupten files. Ist es bitte möglich dass imatch zukünftig bei der Datenbankanalyse, oder / und dem Befehl Verzeichnissaktualisierung aktiv auf solche korrupten Bilddaten hinweißt? Das hat den Vorteil dass ich solche Fehler zeitnah rückgemeldet bekomme und ich dann die Bilder aus meinen backups zurückspielen kann.

Danke.

P.s. ich bin auch auf der Suche was den Fehler für "entire files is binary zeros" bei RAW + jpg. ausgelöst hat. Ich habe nur imatch im Einsatz und keine weitere Software. Merkwürdig ist, dass RAW + jpg. Beschädigt sind.

Gruß Björn

[thrinn]

Verstehe ich das richtig, dass die Dateien selbst nicht mehr lesbar sind? Also nicht nur irgendwelche Metadaten durcheinander sind? Dann bezweifele ich, dass IMatch da viel machen kann, ohne die Dateien komplett "durchzulesen". Das aber würde ewig dauern - es gibt ja User, die 300.000 Dateien oder mehr in IMatch verwalten. Oder welche auf NAS oder anderer Medien ausgelagert haben.

Aber nicht mehr lesbare Dateien sollten doch eigentlich beim Backup auffallen? Das Backup-Programm müsste ja die Dateien lesen, oder?

[Mario]

Wenn ExifTool diese Meldung liefert, wurde die Datei von irgendwas komplett mit Nullen überschrieben. Das ist aber so selten, da lohnt sich kein Feature. Und das würde auch viel zu lange dauern. IMatch-Anwender verwalten zwischen 100,000 und 2 Millionen Dateien pro Datenbank...

IMatch bekommt Änderungen an Dateien beim Rescan des Folders mit (anhand der Prüfsumme) und ließt die Datei neu ein. Wenn dabei ein Fehler gefunden wird, zeigt IMatch das Warnsymbol. Du kannst Dateien mit Fehlern leicht über den Metadaten-Filter Extra\Errors tag oder eine darauf basierende datengestützte Kategorie finden. Das haben wir letzte Woche erst wieder hier in der community besprochen.

Du kannst auch die File Verifier App in IMatch verwenden, um Dateien auf Veränderungen/Beschädigungen zu prüfen (auch wenn sich der Zeitstempel nicht geändert hat). Manche Viren überschrieben Dateien mit Nullen oder Verschlüsseln sie, ohne den Zeitstempel oder die Größe zu ändern...

[spiff]

Verstehe ich das richtig, dass die Dateien selbst nicht mehr lesbar sind? Also nicht nur irgendwelche Metadaten durcheinander sind?

Genau

[spiff]

Du kannst Dateien mit Fehlern leicht über den Metadaten-Filter Extra\Errors tag oder eine darauf basierende datengestützte Kategorie finden. Das haben wir letzte Woche erst wieder hier in der community besprochen.

Kannst du mir das bitte besser erläutern, ich verstehe das so nicht?

Du kannst auch die File Verifier App in IMatch verwenden, um Dateien auf Veränderungen/Beschädigungen zu prüfen (auch wenn sich der Zeitstempel nicht geändert hat). Manche Viren überschrieben Dateien mit Nullen oder Verschlüsseln sie, ohne den Zeitstempel oder die Größe zu ändern...

In deutscher Sprache ist das der Datei-Validierer? Der läuft gerade, läuft aber wesentlich länger als der Befehl Verzeichnis aktualisieren. Deshalb möchte ich noch obige von Dir angesprochene Lösung probieren wenn ich nur wüsste wie?

Gruß Björn

[spiff]

Update: Der Datei Validierer hat 2000 Dateien mit Prüfsummenfehlern gefunden, die aber Stichprobenartig alle noch lesbar waren. ABER: Die hier besprochenen unlesbaren Dateien hat der Validierer NICHT gefunden.

[jch2103]

Extra \ Errors tag data-driven category:

https://www.photools.com/community/index.php?topic=1152.msg13023#msg13023

[Mario]

Danke für den Link.

HINWEIS: Extra\Errors wird von ExifTool gefüllt, wenn es beim Einlesen oder Schreiben von Dateien harte Fehler findet.
Wenn eine Datei nach dem Einlesen von einer externen Quelle verändert wird ohne den Zeitstempel zu ändern, kann IMatch das nicht festellen. Nur wenn Du die Dateien zwangsweise neu einließt.

ABER: Die hier besprochenen unlesbaren Dateien hat der Validierer NICHT gefunden.

Das ist logisch. Wenn die Datei nach der Veränderung neu eingelesen wurde, wurde auch die Prüfsumme in der Datenbank aktualisiert.
Der File Verifier findet Dateien, deren aktuelle Prüfsumme auf der Festplatte von der in der Datenbank gespeicherten Prüfsumme abweicht. Also z.B. wenn eine Datei durch einen Platten- oder Netzwerkfehler beschädigt wird. Oder durch einen Virus.

Hier ist das DYK zum Extra\Error tag

[spiff]

Danke Dir, das hat geklappt! Ich habe in der gesamten DB lediglich 8 Bilder mit diesem Fehler gefunden, von denen knapp die Hälfte nur jpg. waren und aus dem zugehörigen RAW neu erstellt werden konnten. Bei der anderen Hälfte waren RAW + jpg. betroffen und die Bilder sind verloren? Kann mir bitte jemand zeigen wie ich das, was ich über den Filter abgebildet bekomme, in einer eigenen Kategorie hinterlege, die ich bei Bedarf einfach aufrufe?

Bzgl. Prüfummenfehler / Dateivalidierer reicht es auch aus das eine externe Anwendung eine Bilddatei einliest, eventuell XMP editiert, damit die Prüfsumme nicht mehr in Ordnung ist? Von den ca. 2000 Dateien mit Prüfsummenfehlern kann ich in Stichproben alle noch lesen und editieren, sie scheinen in Ordnung zu sein.

[Mario]

damit die Prüfsumme nicht mehr in Ordnung ist?

IMatch ließt dann die Bilddatei doch neu ein und aktualisiert die Proüfsumme. Dann passt das wieder.
Die Prüfsumme ist nur zum Erkennen von Dateien, die "offiziell" nicht verändert wurden und dennoch eine falsche Prüfsumme haben.

Einfach eine datengetriebene Kategorie auf der Basis des Extra\Error tags anlegen.
Die Option "Use Other" auf aus. Dann bekommst Du eine Kindkategorie für jede einzigartige Fehlermeldung. Das habe ich erst neulich in einem Thread erklärt... einfach mal nach Extra\Error suchen.

[spiff]

Das hat geklappt, danke Dir. Der thread wo beschrieben wird wie die Kategorie gebildet wird ist hier:
https://www.photools.com/community/index.php?topic=10918.msg77863#msg77863