Forum: PC Hard- und Software Kopierte Dateien nicht binär identisch?


von Walter T. (nicolas)


Angehängte Dateien:

Lesenswert?

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?

: Bearbeitet durch User
von Harald K. (kirnbichler)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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
von Harald K. (kirnbichler)


Lesenswert?

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.

von Wastl (hartundweichware)


Lesenswert?

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.

von Lu (oszi45)


Lesenswert?

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.

von Walter T. (nicolas)


Angehängte Dateien:

Lesenswert?

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.

von Wastl (hartundweichware)


Lesenswert?

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 ....

von Wastl (hartundweichware)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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.

von Martin M. (capiman)


Lesenswert?

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

von Esmu P. (Firma: privat) (max707)


Lesenswert?

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?

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

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.

von Uwe (uhi)


Lesenswert?

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.

von Lu (oszi45)


Lesenswert?

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

von Rolf M. (rmagnus)


Lesenswert?

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
von G. K. (zumsel)


Lesenswert?

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
von Irgend W. (Firma: egal) (irgendwer)


Lesenswert?

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.

von René H. (mumpel)


Lesenswert?

Weshalb überhaupt einen solchen Aufwand betreiben? Kopieren und gut ist. 
Solange alle Dateien funktionieren, ist es doch wurscht ob irgendwo ein 
Byte fehlt.

von Jens G. (jensig)


Lesenswert?

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?

von Harald K. (kirnbichler)


Lesenswert?

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

von Rolf M. (rmagnus)


Lesenswert?

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.

von Jens M. (schuchkleisser)


Lesenswert?

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.

von Gerald B. (gerald_b)


Lesenswert?

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.

von Harald K. (kirnbichler)


Lesenswert?

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.

von Thomas S. (Firma: Chipwerkstatt) (tom_63)


Lesenswert?

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.

von Lu (oszi45)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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.

von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

> 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.

von Vanye R. (vanye_rijan)


Lesenswert?

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

von Wastl (hartundweichware)


Lesenswert?

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.

von Dieter S. (ds1)


Lesenswert?

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."

von Wastl (hartundweichware)


Lesenswert?

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.

von Daniel G. (denial)


Lesenswert?

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.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

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.

von Harald K. (kirnbichler)


Lesenswert?

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.

von G. K. (zumsel)


Lesenswert?

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
von G. K. (zumsel)


Lesenswert?

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
von Ob S. (Firma: 1984now) (observer)


Lesenswert?

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?

von Harald K. (kirnbichler)


Lesenswert?

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.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

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.

von Harald K. (kirnbichler)


Lesenswert?

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.

von Walter T. (nicolas)


Lesenswert?

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
von G. K. (zumsel)


Lesenswert?

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.

Bitte 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
Noch kein Account? Hier anmelden.