RAW Killer gesucht

[JSB]

Ich habe auch in erster Linie das externe Speichermedium (Drobo) in Verdacht...allerdings ist es interessant, daß sich die Zerstörung ausschliesslich auf Canon CR2 Raw-Dateien beschränkt. Ich bin kein IT-Spezialist aber es fällt mir schwer nachzuvollziehen, warum sich eine eventuelle "Silent Data Corruption" nur auf dieses eine spezielle Dateiformat beziehen sollte.

Wenn das Problem an einem defekten Cardreader oder Kabel liegen sollte, dann müssten die Dateien entweder beim Kopieren von der CF-Karte auf das Laptop oder von dort auf den externen Speicher "corrupted" werden...das erklärt aber immer noch nicht, warum intakte Dateien erst mit der Zeit zerstört werden und eben nur ein bestimmtes Dateiformat.

Es muß etwas mit den Canon CR2 Raw-Dateiformat zu tun haben..was aber auch nicht sehr wahrscheinlich klingt.

[JSB]

Wen das Thema interessieren sollte...zwar keine Erklärung aber immerhin ein konkreter Lösungsvorschlag https://forums.adobe.com/thread/2522618

have also seen this problem when using Lightroom (and possibly Photoshop) using a Drobo 5N with Dual Disk redundancy connected via Wifi with my Lightroom Catalog running off local disk. The corrupted files are Canon Raws. The matching JPG is normally not corrupt (possibly never). The images appear corrupt in other (non-Adobe) programs. Sometimes if I am able to copy the "corrupt" file to another disk and back to the Drobo, the corruption disappears.

Producing a higher recovery rate: I used Chronosync to archive all my images to a portable hard drive and then restored them back to the Drobo and, as far as I can tell, ALL the corruption was cured. (But the problem still spontaneously happens while I use Lightroom.) Sometimes a Chronosync backup had to be run more than once to copy all images. (Some files produced errors or were skipped with a first run and successfully copied with a second run.

[hs]

Ich habe auch in erster Linie das externe Speichermedium (Drobo) in Verdacht...

Upps, da habe ich deinen relevanten Satz mit dem "vorher intakt" überlesen.

allerdings ist es interessant, daß sich die Zerstörung ausschliesslich auf Canon CR2 Raw-Dateien beschränkt.

Und ich dachte immer CR steht für "Canon Raw" und nicht für "corrupt". *scnr*

Ich bin kein IT-Spezialist aber es fällt mir schwer nachzuvollziehen, warum sich eine eventuelle "Silent Data Corruption" nur auf dieses eine spezielle Dateiformat beziehen sollte.

Das siehst Du richtig, CR2 und NEF sind letztendlich beides Binärdateien.

... dann müssten die Dateien entweder beim Kopieren von der CF-Karte auf das Laptop oder ...

Jeder Kopiervorgang kann natürlich die Daten auf dem Zielsystem korrumpieren, weswegen es sicherer ist Original und Kopie nochmals *binär* zu vergleichen.

Es muß etwas mit den Canon CR2 Raw-Dateiformat zu tun haben..was aber auch nicht sehr wahrscheinlich klingt.

Dann ist es wahrscheinlich dass es mit Software zu tun hat. Denkbar wäre ein "Canon Hasser Virus" oder Adobe hat einen Riesen-Bug eingebaut und hält sich nicht an die Vorgabe Raws in Ruhe zu lassen.

[JensLPZ]

Ich hatte mal ein ähnliches Problem, da war es der Cardreader.

@ TO
Das wirst nur durch das "Ausschlussverfahren" lösen können.

[Thomas Madel]

Das wirst nur durch das "Ausschlussverfahren" lösen können.

Der TO schreibt eindeutig: "Die Zerstörung betrifft auch Raw-Dateien, die noch vor kurzer Zeit völlig in Ordnung waren..."

Es gehen also ursprungliche funktionierende Dateien auf diesem Drobo-Teil im Laufe der Zeit kaputt. Das zeigt ziemlich eindeutig, dass das Drobo-Laufwerk die Fehlerquelle ist. Die Links zu verschiedenen Foren gehen auch alle in diese Richtung. Meine Entscheidung wäre da schnell gefallen, das Drobo Dingens muss gehen und wird durch etwas zuverlässig funktionierendes ersetzt.

[TimFokus]

Ich würde nicht so weit gehen und generell das Drobo verteufeln..... In den meisten Fällen liegt der Teufel im Zusammenspiel der Komponenten / Betriebssysteme. Kann sein, du nimmst einen Windowsrechner und die Dateien sind ok........

[Thomas Madel]

Ich würde nicht so weit gehen und generell das Drobo verteufeln..... In den meisten Fällen liegt der Teufel im Zusammenspiel der Komponenten / Betriebssysteme. Kann sein, du nimmst einen Windowsrechner und die Dateien sind ok........

Ich will das Ding nicht verteufeln, würde es aber ganz einfach nicht mehr nutzen wollen, wenn es meines wäre. Das es an einem Windows Rechner funktionieren könnte, hilft einem Mac-User in der Regel wenig.

Mein Meinung ist, dass es Datenspeicher Daten so zu speichern hat, dass diese möglichst sicher "verwahrt" sind. Wenn der Speicher Daten zerstört oder beschädigt ist das nicht akzeptabel und wenn es systembedingt sein sollte, ist das System unbrauchbar. So etwas ist eine tickende Zeitbombe.
Es gibt genügend Anbieter, die funktionierende Raid-Systeme im Programm haben. Deshalb würde ich mir das oder die Drobo nicht antun, wenn ich es als Speichermedium für meine Fotos verwenden möchte, diese aber beschädigt oder unbrauchbar werden können. Im Zweifelsfall ist ja nur das Gehäuse auszutauschen, die Platten würde ja in einem anderen Gehäuse funktionieren. Hier würde ich ein Ende mit Schrecken (Geld ausgeben, Zeitaufwand...) einem Schrecken ohne Ende vorziehen. Woher soll der TO wissen, welche RAWs nächsten Monat über den Jordan gehen...

[JensLPZ]

Der TO schreibt eindeutig: "Die Zerstörung betrifft auch Raw-Dateien, die noch vor kurzer Zeit völlig in Ordnung waren..."

Ich las.

Betraf das nun die beim erneuten Kopieren von der Karte auf die Platte oder beim erneuten Importieren in LR vom externen Medium?

[Hans Joerg Nahm]

Eventuell eine Datei zum runterladen hier einstellen, um zu sehen ob auf fremden Rechner das gleiche Problem auftritt

[hs]

Es gibt *sch* Fehler, die man lange nicht versteht, wenn überhaupt, und einem die Haare raufen lassen.

Folgendes ist sicher schwer verständlich für nicht SW Entwickler, aber ich hoffe das Problem doch erklären zu können.

Ein einigermaßen anschaulicher Fehler, der gut 25 Jahre her ist. Damals hatte ein von uns verwendeter FDDI Treiber von Schneider & Koch das Problem die segmentierten Pakete bei der Übertragung unter bestimmenten (mir nicht genauer bekannten) Umständen an den Segmentgrenzen zu korrumpieren. Damals wurden die Daten noch nicht dynamisch erzeugt und gestreamt, sondern noch als riesige "arrays of struct" (übersetzt vielleicht riesige "Daten-Matrizen") definiert.

Ich versuche mal zu übersetzen:
- Software definiert und verwaltet Daten
- damals hat die Software, der einfachheit halber, ein Maximum an Daten definiert (z.B. 1 MB Daten, es waren sicher weniger)
- ein leerer Datensatz (im Bsp. 1 MB) war initialisiert (also binäre Wüsten mit Hex 0, komprimiert also wenige Byte )
- da man die 1 MB nicht im Block übertragen kann werden die Daten (also 1 MB Nullen) in passende Stücken geschnitten (segmentiert), per LAN verschifft, und wieder zusammengebaut

Besagter Treiber hatte wie gesagt ein Problem beim Zerstückeln und wieder Zusammenbauen. An den Schnittstellen gab es ab und zu ein paar "uninitialisierte, undefinierte und gekippte Bits". Dies führte dazu das unsere Software bisweilen mit obskuren Fehlern abstürzte, die wir uns nicht erklären konnten.

Erst als wir den Hex-Dump des Parametersatzes untersucht hatten fiel uns auf das große Bereiche, die eigentlich leer sein sollten (eben Hex 0) ab und zu "Dreckbytes" enthielten. D.h. alles drum herum war richtig initialisiert, also Hex 0, aber ab und zu ein paar "uninitialisierte, undefinierte und gekippte Bits". Solch ein Fehler an der richtigen Stelle (z.B. in einem directory) und viel Spaß mit der Fehlersuche.

So ein Fehler könnte auch der Grund sein warum nur CR2 betroffen ist, vielleicht speichert CR2 genau an der problematischen Position wichtige Informationen, während NEF und Co. da Pixelwüsten haben, wo Bit-Kipper völlig irrelevant sind.

Wie gesagt dieses Bsp. ist noch einigermaßen anschaulich, übel wird es wenn Laufzeitverhalten und Parallelverarbeitung eine Rolle spielen (z.B. wenn einer bereits abholt aber der andere noch nicht fertig geliefert hat). Ein Cache meldet z.B. Vollzug wenn er die Daten vollständig empfangen hat (damit es schnell weiter geht). Die sind dann aber i.a. noch nicht geschrieben (da ja erst im Cache). Wenn dann jemand (nicht über den Zwischenpuffer Cache) Daten abholt, dann sind die Daten korrupt.

Solche Fehler passieren ganz, ganz selten, denn nur indeterministische Fehler werden nicht entdeckt.

Ich schließe mich Thomas an und würde das Dobro verkaufen. Ein RAID muss funktionieren, und ich muss mich darauf verlassen können. Fehlersuche sinnlos (da dies auch der Hersteller nicht geschafft hat).