ich habe gerade mehrere tausend Dateien von einer SDXC-Speicherkarte auf eine andere kopiert. Beim Vergleich der Ordnerstruktur mit WinMerge wird eine einzelne Datei als "nicht identisch" mit seiner Kopie angezeigt.
Auf beiden Speicherkarten ist das Dateisystem NTFS. Betriebssystem ist Windows 11. Kopiert wurde mit dem Windows-Dateimanager. Bei der Datei handelt es sich um einen 63 MB großen MP4-Container. Beide Filme lassen sich abspielen und sind auch gleich lang.
Die Ziel-Speicherkarte wurde vorher mit H2testw komplett durchgetestet (was 28 Stunden gedauert hat) und als fehlerfrei bewertet.
(Binärdateien würde ich mit einem Binär-, und nicht einem Textvergleicher vergleichen, aber das ist hier nebensächlich).
Vielleicht sinds nur irgendwelche Metadaten, die da umgekippt sind; wer weiß das schon? Man bräuchte ein Programm zur mp4-Analyse, um herauszufinden, in was für einem Bereich der Datei die Abweichungen liegen.
(Binärdateien würde ich mit einem Binär-, und nicht einem
Textvergleicher vergleichen, aber das ist hier nebensächlich).
Eigentlich ist’s nicht nebensächlich: Mit einem Diff der Hexdumps würde man ausgezeichnet sehen, ob vielleicht nur ein Bit gekippt ist. Möglich ist’s, hatte ich gerade bei häufig genutzten μSD-Karten auch schon das eine oder andere Mal.
Ich tippe mal auf ein mistiges Interface zur Speicherkarte. Muss
ja wahrscheinlich USB sein ....
Ich habe ältere USB-zu-IDE/SATA Interface Kabel. Die können
schon ab und zu mal ein Byte kippen lassen. Auch die (evtl.
schwächliche) Stromversorgung kann eine Rolle spielen.
Beim Kopieren von wichtigen Daten (meistens sind sie ja
wichtig) nutze ich den Total Commander mit Verifikation.
Eigentlich ist’s nicht nebensächlich: Mit einem Diff der Hexdumps ...
Ich fand die grafische Darstellung angenehmer, weil man da sofort sieht, dass die Unterschiede irgendwo in der Mitte der Dateien, und nicht am Anfang und nicht am Ende sind. Dass die Unterschiede alle Einzelbits zu sein scheinen, sah man ja auch. Bei WinMerge hat man beim Binärvergleich wohl keine Streifenübersicht der Unterschiede. Ich habe aber auch mal den Binärvergleich angehängt.
Ich tippe mal auf ein mistiges Interface zur Speicherkarte. Muss
ja wahrscheinlich USB sein ....
Die Quell-SDXC-Karte steckte im internen Speicherkartenleser des Laptops, die Ziel-Karte in einem USB-Kartenleser. Jetzt, bei der der Kontrolle, ist es umgekehrt. Insgesamt wurden 3530 Dateien kopiert, (mindestens) 2 sind unterschiedlich (der Vergleich läuft noch).
Die zweite unterschiedliche Datei ist ein DVD-Image (*.iso).
Irgendwie verstört mich das gerade. Ich dachte, es sei Zweck eines Flash-Controllers, Einzelbitfehler zu kompensieren.
Der Stomverbrauch von SD-Karten ist potentiell, punktuell
hoch und der Platz für DC Abblockung in den Gerätchen ist
meist zu klein oder zu teuer oder beides ....
Dass die Unterschiede alle Einzelbits zu
sein scheinen, sah man ja auch.
Gut, mag auch an mir liegen: Ich hab die Bitmuster von , und ~ nicht vor Augen, während sie bei hexadezimalen Zahlen für mich sofort ersichtlich wären, und in binärer Darstellung für jeden. Entschuldige die Störung.
Dass die Unterschiede alle Einzelbits zu
sein scheinen, sah man ja auch.
Gut, mag auch an mir liegen: Ich hab die Bitmuster von , und ~ nicht vor
Augen, während sie bei hexadezimalen Zahlen für mich sofort ersichtlich
wären, und in binärer Darstellung für jeden. Entschuldige die Störung.
ich habe gerade mehrere tausend Dateien von einer SDXC-Speicherkarte auf
eine andere kopiert. Beim Vergleich der Ordnerstruktur mit WinMerge wird
eine einzelne Datei als "nicht identisch" mit seiner Kopie angezeigt.
Das kann durchaus passieren.
Bei der Datei
handelt es sich um einen 63 MB großen MP4-Container. Beide Filme lassen
sich abspielen und sind auch gleich lang.
Ja, Videoformate sind schon vom Grundkonzept her "in der Masse" recht fehlertolerant. Kommt halt darauf an, wo genau das Bit gekippt ist. Von dem Fall, dass nicht mal sicht- oder hörbare Störungen auftreten bis hin zu dem Fall, dass die Wiedergabe abbricht, ist so ziemlich alles möglich. Am weitaus wahrscheinlichsten gibt es aber eine durchaus sichtbare Bildstörung für die Dauer einer "GOP". Der Begriff ist hier nicht im engen Sinne seiner ursprünglichen Definition bei MPEG1/2 zu sehen, sondern allgemeiner im Sinn von "Bereich zwischen zwei Keyframes".
Jedenfalls muss man, um diese wahrscheinlichsten Fehler zu sehen, schon relativ aufmerksam zuschauen. Mal kurz in die Chipstüte gucken und schon hast du die entscheidende Sekunde verpasst, in der der Fehler zu sehen ist.
Die Ziel-Speicherkarte wurde vorher mit H2testw komplett durchgetestet
(was 28 Stunden gedauert hat) und als fehlerfrei bewertet.
Was kann hier passiert sein?
Lesefehler der Quellkarte dürfte am wahscheinlichsten sein.
Möglich ist aber auch ein sporadische Bitfehler bei einem der vielen beteiligten Busse bzw. Interlinks durch Strahlung. Das ist durchaus kein Witz. Die Atmosphäre hält sehr viel der kosmischen Strahlung ab, aber nicht alles. Auch der Boden und Baustoffe haben eine natürliche Radioktivität.
Das zusammen sorgt dafür, dass Bitfehler bei Computern über kurz oder lang sicher auftreten werden. Ist nur eine Frage der Zeit. Allerdings: In den allermeisten Fällen merkt man nichts davon, weil sie halt an unwichtigen Stellen auftreten. Trotzdem haben z.B. Server typisch Gegenmaßnahmen für RAM-Fehler eingebaut. Manchmal treten die Bitfehler eben auch an wichtigen Stellen auf und das möchte man gerne bemerken, bevor größere Folgeschäden entstehen.
Je größer die Blöcke sind, desto eher kann der Fehler auch wieder durch andere Fehler ausgebügelt werden. Deswegen testet man gelegentlich mit 2 verschiedenen Methoden. z.B. https://www.heise.de/download/product/winmd5checksum-92313
Solche Probleme sollen auch schon durch fehlerhaften RAM im Rechner ausgelöst worden sein. Wenn der Fehler in einem Bereich liegt, den das System immer für den Cache benutzt, dann kann es sein, dass er sich nicht oder kaum durch Abstürze, sondern nur durch fehlerhaft rausgeschriebene Daten bemerkbar macht - vor allem beim Kopieren größerer Datenmengen, wenn der Cache besonders intensiv genutzt wird.
Man darf generell nicht vergessen, dass der Weg von der einen Karte bis zur anderen ziemlich lang ist, und nicht alles davon ist CRC-überwacht. Fehler können potenziell überall auf diesem Weg auftreten, nicht nur in den Karten selbst.
Irgendwie verstört mich das gerade. Ich dachte, es sei Zweck eines
Flash-Controllers, Einzelbitfehler zu kompensieren.
Mich auch. Ich hätte erwartet, dass da Checksummen über Blöcke verwendet
werden, die Fehler zuverlässig erkennen.
Das ganze greift aber nicht ende zu ende.
Der Flashcontroller macht das eben nur in Richtung der (eigenen) Flashchips.
Du hast aber noch eine ganze Reihe von weiteren Übertragungsabschnitten bis die Daten am Ziel ankommen.
Solche Probleme sollen auch schon durch fehlerhaften RAM im Rechner
ausgelöst worden sein...
Jo, der RAM ist durchaus ein guter Kandidat für solche Fehler.
Systematisch ausprobieren, indem man ermittelt ob es am Lesenden zweig, am dazwischen liegenden Rechner oder am Ziel liegt. Mal für die Quelle einen anderen Kartenleser verwenden. Die Daten mal auf eine andere Platte kopieren usw. Am besten mehrfach und jedesmal vergleichen ob alles fehlerfrei ist.
Weshalb überhaupt einen solchen Aufwand betreiben? Kopieren und gut ist. Solange alle Dateien funktionieren, ist es doch wurscht ob irgendwo ein Byte fehlt.
Weshalb überhaupt einen solchen Aufwand betreiben? Kopieren und gut ist.
Solange alle Dateien funktionieren, ist es doch wurscht ob irgendwo ein
Byte fehlt.
Du testest alle Dateien nach dem Kopieren auf komplette Funktionsfähigkeit und Lesbarkeit?
Weshalb überhaupt einen solchen Aufwand betreiben? Kopieren und gut ist.
Solange alle Dateien funktionieren, ist es doch wurscht ob irgendwo ein
Byte fehlt.
Wenn das ein systematischer Fehler ist, der immer wieder auftritt, ist es nur eine Frage der Zeit, bis man Dateien hat, die eben nicht trotz Fehler zufälligerweise immer noch funktionieren. Abgesehen davon ist wie schon gesagt wurde, der Aufwand, alle Dateien nochmal auf Funktion zu überprüfen eher höher als Bit-für-Bit-Vergleich mit erneutem Kopieren beschädigter Dateien. Ob eine kaputte Datei noch einwandfrei funktioniert, kann im übrigen auch von der Software bzw. dem Gerät, das sie verarbeitet, abhängen.
Deswegen kopiere ich mit TeraCopy, das kann hinterher via CRC testen ob's geklappt hat.
In diesem Fall würde man die gefailten Dateien einfach nochmal übertragen und gut, geht mit wenigen Mausklicks innerhalb des Dialogs.
Rauszufinden was wirklich passiert ist ist schwierig bei temporären Fehlern, aber auch sinnlos.
Eine andere Kopie hat man nicht, also einfach nochmal übertragen, vergleichen und freuen.
Besorge dir ein Tool, das Prüfsummen aus Dateien errechnen kann. Dann liest du mehrmals die selbe Datei ein. Das machst du von der Quelle und vom Ziel. Eventuell tut sich ja dabei schon was. Wenn du Bei Kartenleser A Kippler hast und bei B nicht, dann kannst du bersuchen, von B zu lesen, die Datei auf Platte zu parken und dann die Datei auf der anderen Karte wieder auf B zu schreiben.
Ist mühselig, aber anders ist dem nicht beizukommen.
Ein RAM Test läuft quasi von allein, der kann wie vor mir schon gesagt, auch nicht schaden.
Man könnte die Anzahl der Fehlerquellen reduzieren, indem man nur einen Kartenleser verwendet und die Dateien auf der Festplatte/SSD des kopierenden Rechners zwischenlagert.
Die Annahme, daß die zuverlässiger funktioniert, als die beteiligten Kartenleser und SD-Karten, die setze ich jetzt mal voraus.
Man könnte den Kopiervorgang auf die Festplatte/SSD wiederholen (Ziel jeweils ein anderes Verzeichnis) und dann die Kopien vergleichen (bzw. mit md5sum oder einem ähnlichen Werkzeug Prüfsummen davon erstellen lassen).
Hat man den Eindruck gewonnen, daß das einigermaßen geklappt hat, dann kann man in die entgegengesetzte Richtung kopieren, von Festplatte/SSD auf den zum Lesen verwendeten Kartenleser.
Ob ein einfacher RAM-Test zur Diagnose hilft, weiß man nicht, da einfaches füllen der Speicher mit 00 und FF selten reicht. Mancher RAM-Fehler trat erst nach Stunden und mit Zufallszahlen oder im praktischen Betrieb auf. Wahrscheinlich würde ich eher die Dateien mit MD5-Prüfzahlen überwachen.
Ob ein einfacher RAM-Test zur Diagnose hilft, weiß man nicht, da
einfaches füllen der Speicher mit 00 und FF selten reicht. Mancher
RAM-Fehler trat erst nach Stunden und mit Zufallszahlen oder im
praktischen Betrieb auf.
Memtest86 kann vom Stick gebootet werden, sodass alle Bereiche des RAM geprüft werden können, und wenn das nach einigen Stunden verschiedener Testmuster und -strategien dann anzeigt, dass es keinen Fehler gefunden hat, dann kann man den RAM von der Liste der Verdächtigen streichen. Kann nicht schaden, das hier mal laufen zu lassen.
ich habe gerade mehrere tausend Dateien von einer SDXC-Speicherkarte auf
eine andere kopiert. Beim Vergleich der Ordnerstruktur mit WinMerge wird
eine einzelne Datei als "nicht identisch" mit seiner Kopie angezeigt.
Nimm mal ein anderes tool als Winmerge.
IMHO kann man dem Winmerge auch ein anderes diff-tool unterschieben. Bei kurzen "Überfliegen" des Ausdrucks ist jedenfalls kein zwingender bit-fehler zu erkennen.
Habt ihr bei eurer Einschaetzung der Sachlage beruecksichtigt das die Datenverbindung vom Controller im Kartenleser zur SD-Karte mit Pruefsummen abgesichert ist? Da sollte also kein Fehler passieren ohne das dies auffaellt.
Habt ihr bei eurer Einschaetzung der Sachlage beruecksichtigt das die
Datenverbindung vom Controller im Kartenleser zur SD-Karte mit
Pruefsummen abgesichert ist?
Das mag sein, aber die Übertragung vom USB zum Flash Controller
nicht.
Ich habe noch nie beim USB Protokoll etwas zu CRC o.Ä. gehört.
Ich habe noch nie beim USB Protokoll etwas zu CRC o.Ä. gehört.
Einfach mal die Spezifikation zu USB lesen, z.B. unter "Robustness":
"CRC protection over control and data fields"
Oder etwas mehr:
"The protocol includes separate CRCs for control and data fields of each packet. A failed CRC is considered to indicate a corrupted packet. The CRC gives 100% coverage on single- and double-bit errors."
Na dann hoffen wir mal dass das ausreicht eine fehlerfreie
Datenübertragung zur SD Card zu gewährleisten.
Bei meinen schon erwähnten USB-zu-IDE/SATA Controllern hat
es manchmal nicht gereicht. Aber das muss ja dann nicht am
"schlechten" CRC des USB Protokolls liegen.
Habt ihr bei eurer Einschaetzung der Sachlage beruecksichtigt das die
Datenverbindung vom Controller im Kartenleser zur SD-Karte mit
Pruefsummen abgesichert ist? Da sollte also kein Fehler passieren ohne
das dies auffaellt.
Pruefsummen können keine 100%-Sicherheit herstellen, nicht mal die wirklich Guten können das. Sie können Fehler immer nur mit einer gewissen Wahrscheinlichkeit detektieren, die aber in jedem Fall unter 100% liegt.
Pruefsummen können keine 100%-Sicherheit herstellen, nicht mal die
wirklich Guten können das
Allerdings ist bereits bei so etwas anspruchsarmen wie MD5 die Wahrscheinlichkeit, zwei Dateien unterschiedlichen Inhalts, aber gleicher Prüfsumme zu erhalten, überaus überschaubar. Insofern ist Deine Einlassung zwar theoretisch zutreffend, aber mit einer gewissen Praxisferne versehen.
Bei einem 16-Bit-CRC kann es naturgemäß nur 2^16 unterschiedliche Dateien geben, MD5 arbeitet mit 128 Bit, was die Anzahl unterschiedlicher Dateien auf 2^128 erhöht. Ich denke, da spiele ich lieber Lotto, die Wahrscheinlichkeit auf einen Jackpot oder wie auch immer das heißt, ist da deutlich höher.
Bei einem 16-Bit-CRC kann es naturgemäß nur 2^16 unterschiedliche
Dateien geben, MD5 arbeitet mit 128 Bit, was die Anzahl
unterschiedlicher Dateien auf 2^128 erhöht. Ich denke, da spiele ich
lieber Lotto, die Wahrscheinlichkeit auf einen Jackpot oder wie auch
immer das heißt, ist da deutlich höher.
Hier was schnelles (liest beide Verzeichnisse parallel und und diese dann jeweils mit 4 Jobs parallel) hingewurstelt mit sha256: (Kann man auch auf blake3 oder sha512 umfrickeln):
Man könnte den Kopiervorgang auf die Festplatte/SSD wiederholen (Ziel
jeweils ein anderes Verzeichnis) und dann die Kopien vergleichen (bzw.
mit md5sum oder einem ähnlichen Werkzeug Prüfsummen davon erstellen
lassen).
Allerdings sollte man vorher/zwischendurch den Plattencache löschen:
Pruefsummen können keine 100%-Sicherheit herstellen, nicht mal die
wirklich Guten können das
Allerdings ist bereits bei so etwas anspruchsarmen wie MD5 die
Ja, allerdings bezog ich mich auf die Aussage von Vanye R. bezüglich der Absicherung des SD-Karten-Transfers. Wäre mir neu, dass hier MD5 verwendet wird. Kennst du irgendwelche geheimen Erweiterungen des Standards, an die Normalsterbliche wie ich nicht herankommen?
Ja, allerdings bezog ich mich auf die Aussage von Vanye R. bezüglich der
Absicherung des SD-Karten-Transfers.
Da Du "Prüfsummen" und "die wirklich guten" schriebst, las ich das als
Verallgemeinerung.
Ich schrieb selbst die wirklich Guten, um zart darauf hinzuweisen, dass es sich bei SD-Transfers gerade nicht um solche handelt.
Die Verallgemeinerung bezog sich dann auf die Gesetzmäßigkeit, dass 100% unmöglich zu erreichen sind, was ja nunmal tatsächlich ein Naturgesetz darstellt, wie du ja auch zugegeben hast.
Ich schrieb selbst die wirklich Guten, um zart darauf hinzuweisen,
dass es sich bei SD-Transfers gerade nicht um solche handelt.
Das magst Du so beabsichtigt haben, hast es aber nicht getan.
Ist aber auch wurscht: Hier gibt es eine Vielzahl möglicher Fehlerquellen, die in ihrer Kombination (zwei verschiedene SD-Karten-Leser, USB-Kabel etc.) die Fehlersuche sicherlich nicht vereinfachen.
Da der Threadstarter hier schon seit einigen Tagen nicht mehr beteiligt zu sein scheint, dürfte sich das Thema eh' erledigt haben.
seit einigen Tagen [...] dürfte sich das Thema eh' erledigt haben.
Am Wochenende habe ich keine Lust auf Computer.
Ich bin noch am hadern, welche Schlüsse ich aus der Sache schließen soll.
Zwei von 3530 Dateien haben Einzelbit-Abweichungen. Eine Datei ist mittelgroß, eine groß. Der MP4-Container ist noch einwandfrei abspielbar, das ISO-Image ist defekt.
Das ISO-Image ist allerdings auf der Quell-SDXC-Card auch schon defekt. (Das ist in sich erst einmal nicht weiter schlimm - in irgendeinem alten Backup wird noch eine intakte Version stecken.** ) Die Einzelbit-Abweichungen sind nicht systematisch. Manchmal ist das Byte auf der Quell-Karte größer, manchmal auf der Ziel-Karte.
Jetzt ist die Frage: Liegt es an der Karte oder am Kartenleser im Laptop?
Der Fehler ist ja immer noch so sporadisch, dass ich keine Chance habe, das systematisch zu testen. Damit habe ich auch eigentlich keine Chance, das Datenverlustrisiko irgendwie akzeptabel zu halten. Wenn Prüfsummen + Prüfungen nicht von sich aus im System integriert sind, finden sie realistisch gesehen nicht statt.
Nachtrag/Plot Twist: Im Backup von 2014 ist die ISO-Datei auch schon defekt. Binär ist sie allerdings mit keiner der anderen beiden Varianten auf den SDXC-Karten identisch. WTF?
Nachtrag/Plot Twist: Im Backup von 2014 ist die ISO-Datei auch schon
defekt. Binär ist sie allerdings mit keiner der anderen beiden Varianten
auf den SDXC-Karten identisch. WTF?
Es gibt solche Sachen wie ECC und ZFS nicht ohne Grund.
Screenshot_2025-03-07_172218.png
(210 KB)
