Announcement: there is an English version of this forum on 
Hallo, 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. Was kann hier passiert sein?
Angehängte Dateien:
:
Bearbeitet durch User
Walter T. schrieb: > Was kann hier passiert sein? Lesefehler bei Quell-Speicherkarte? (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.
Harald K. schrieb: > (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.
:
Bearbeitet durch User
Ich bezog das "nebensächlich" darauf, daß überhaupt ein Unterschied
entdeckt wurde; Dein Argument hat jedoch durchaus auch seinen Wert.
Das kann Windows auch mit Bordmitteln:
fc dateiA dateiB /b
in der Kommandozeile ... listet nur die unterschiedlichen Bytes auf.
Walter T. schrieb: > Was kann hier passiert sein? Harald K. schrieb: > Lesefehler bei Quell-Speicherkarte? 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.
Man könnte diese Datei zum Test nochmals auf das gleiche Medium kopieren und dann prüfen? robocopy /? ist auch ein schöner Befehl zum kopieren.
Jack V. schrieb: > 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. Wastl schrieb: > 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.
Walter T. schrieb: > die Ziel-Karte in einem USB-Kartenleser Und da passiert vermutlich der Mist. 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 ....
Walter T. schrieb: > Irgendwie verstört mich das gerade. Ich dachte, es sei Zweck eines > Flash-Controllers, Einzelbitfehler zu kompensieren. Haha. Der Flash Controller flasht das was er vom USB bekommt. Er kann nicht beurteilen welches Byte richtig oder falsch ist.
Walter T. schrieb: > 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.
Jack V. schrieb: > Walter T. schrieb: >> 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. Hex-Diff -> 07.03.2025 18:16
Wastl schrieb: > Walter T. schrieb: >> Was kann hier passiert sein? > > Harald K. schrieb: >> Lesefehler bei Quell-Speicherkarte? > Beim Kopieren von wichtigen Daten (meistens sind sie ja > wichtig) nutze ich den Total Commander mit Verifikation. Macht man das nicht immer so? Copy/Verify?
Walter T. schrieb: > 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.
Walter T. schrieb: > 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.
Uwe schrieb: > hätte erwartet, dass da Checksummen über Blöcke 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.
:
Bearbeitet durch User
Rolf M. schrieb: > Solche Probleme sollen auch schon durch fehlerhaften RAM im Rechner > ausgelöst worden sein. Jetzt mach doch nicht das überteuerte Overclocker Spielzeug-RAM mit RGB-Blink und die tollen Spielzeug-CPUs von Intel ohne ECC schlecht.
:
Bearbeitet durch User
Uwe schrieb: > Walter T. schrieb: >> 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. Rolf M. schrieb: > 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.
René H. schrieb: > 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?
Jens G. schrieb: > Du testest alle Dateien nach dem Kopieren auf komplette > Funktionsfähigkeit und Lesbarkeit? Ist doch kein Thema. Sind doch nur Walter T. schrieb: > mehrere tausend Dateien
René H. schrieb: > 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.
Jesses. 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.
Harald K. schrieb: > Binärdateien würde ich mit einem Binär-, und nicht einem > Textvergleicher vergleichen, Winmerge testet Binär-Dateien auch binär. Es heiß ja auch, 'Binärdateien sind identisch.
Fc-Befehl und MD5 siehe bereits weiter oben. 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.
Lu schrieb: > 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. Vanye
Vanye R. schrieb: > 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.
Wastl schrieb: > > 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."
Lass ich mich gerne belehren. 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. Wastl schrieb: > Ich habe ältere USB-zu-IDE/SATA Interface Kabel. Die können > schon ab und zu mal ein Byte kippen lassen.
Wastl schrieb: > Ich tippe mal auf ein mistiges Interface zur Speicherkarte. Muss > ja wahrscheinlich USB sein .... USB ist CRC-Geschützt, das SD Interface auch. Das RAM des PCs hingegen nicht.
Vanye R. schrieb: > 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.
Ob S. schrieb: > 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.
Harald K. schrieb: > 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):
1 | #!/bin/sh
|
2 | [ -d $1 ] || ( echo "not exists: " $1; exit 1) |
3 | [ -d $2 ] || ( echo "not exists: " $2; exit 1) |
4 | |
5 | export dir1="$1" |
6 | export dir2="$2" |
7 | |
8 | (echo -n "$dir1\000"; echo -n "$dir2\000") | xargs -0 -i -n1 -P2 sh -c "find '{}' -type f -print0 | xargs -0 -P 4 -n 8 sha256sum" | |
9 | awk ' |
10 | BEGIN { |
11 | FIELDWIDTHS="66 400000000"; dir1 = ENVIRON["dir1"] "/"; dir2 = ENVIRON["dir2"] "/"; |
12 | }
|
13 | $2 ~ "^" dir1 { |
14 | gsub("^" dir1, "", $2); |
15 | if (h["2"][$2] == $1) { |
16 | delete h["2"][$2]; |
17 | } else { |
18 | h["1"][$2] = $1; |
19 | }
|
20 | }
|
21 | $2 ~ "^" dir2 { |
22 | gsub("^" dir2, "", $2); |
23 | if (h["1"][$2] == $1) { |
24 | delete h["1"][$2]; |
25 | } else { |
26 | h["2"][$2] = $1; |
27 | }
|
28 | }
|
29 | END { |
30 | for (i in h["1"]) { |
31 | if(h["1"][i] == h["2"][i]) { |
32 | delete h["1"][i]; delete h["2"][i]; |
33 | }
|
34 | }
|
35 | for (i in h["2"]) { |
36 | if(h["2"][i] == h["1"][i]) { |
37 | delete h["2"][i]; delete h["1"][i]; |
38 | }
|
39 | }
|
40 | for (i in h["1"]) { |
41 | print i " " h["1"][i]; |
42 | }
|
43 | for (i in h["2"]) { |
44 | print i " " h["2"][i]; |
45 | }
|
46 | |
47 | }
|
48 | '
|
:
Bearbeitet durch User
Harald K. schrieb: > 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: https://www.geeksforgeeks.org/how-to-clear-ram-memory-cache-buffer-and-swap-space-on-linux/
:
Bearbeitet durch User
Harald K. schrieb: > Ob S. schrieb: >> 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?
Ob S. schrieb: > 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.
Harald K. schrieb: > Ob S. schrieb: >> 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.
Ob S. schrieb: > 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.
Harald K. schrieb: > 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?
:
Bearbeitet durch User
Walter T. schrieb: > 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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.