Forum: PC Hard- und Software Datei mit unterschiedlichen Checksummen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Thorsten .. (tms320)


Bewertung
1 lesenswert
nicht lesenswert
Hallo zusammen,

ich bin gerade bisschen am Rätseln.

Folgendes: in meinem PC ist eine M.2 SSD als Systemlaufwerk und eine 
normale Festplatte mit 1TB eingebaut. Hab nun mit Macrium Reflect von 
der SSD ein Image erstellt mit Ziellaufwerk eben diese 1TB Festplatte. 
Soweit alles gut, keine Fehler. Das Verify war ok. Nun habe ich diese 
Image-Datei (ca. 150GB) kopiert auf
- externe USB-Festplatte
- externe USB-SSD (anderer Port als die USB-Festplatte verwendet)
- NAS
Habe die Datei nun also auf 4 verschiedenen Laufwerken vorliegen. Wenn 
ich nun von diesen Dateien den SHA-256 berechnen lasse, erhalte ich 4 
(!) verschiedene Werte. Es kann doch nicht sein, dass bei allen 
Kopiervorgängen Fehler aufgetreten sind, oder doch? Oder habe ich hier 
ein Denkfehler? Ich hätte jetzt bei allen 4 Dateien den gleichen 
Hashwert erwartet, da der Inhalt ja identisch sein sollte. Alle 
Laufwerke mit Ausnahme des NAS sind übrigens NTFS formatiert.

Was meint ihr?

Danke und Gruß

Thorsten

: Bearbeitet durch User
von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich tippe auf einen "Messfehler". Sicher, dass das verwendete Tool nur 
ein Hash des reinen Dateiinhalts erzeugt und nicht weitere Kriterien wie 
den Pfad oder das Modifikationsdatum mit reinpackt?

von Mathias A. (mrdelphi)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

Sehe keinen Denkfehler, hätte ich genauso erwartet. Mein nächster 
Schritt wäre, die Dateien mal byteweise zu vergleichen. Sind da 
Unterschiede zu sehen?

von Thorsten .. (tms320)


Bewertung
0 lesenswert
nicht lesenswert
Byteweise vergleichen ist eine gute Idee, bin ich jetzt gar nicht drauf 
gekommen:)

Werde ich gleich mal machen.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Also ich würde ja eher auf ein defektes Kabel oder fehlerhaftes RAM 
tippen.

Wenn ein Hashprogramm, das von Dateien Hashwerte erstellen soll, noch 
systembedingte Metadaten einfügt, dann taugt es nichts.
Und das müsste dann schon ein ziemliches Nischenhashprogramm sein.
Ein Tool das von einer großen Menge an Leute benutzt wird, dürfte solche 
Fehler nicht machen, weil das schnell auffallen würde.

Das Packprogramm 7z bietet unter Windows eine Erweiterung für den 
Dateimanager von Windows an, das Prüfsummen von Dateien erstellen und 
anzeigen kann.
Ansonsten kann man auch git für Windows installieren, das liefert dann 
eine Basherweiterung mit und in der sind die üblichen Programme wie 
sha256sum zugänglich.

von Thorsten .. (tms320)


Bewertung
1 lesenswert
nicht lesenswert
Es ist tatsächlich so, dass die Datein unterschiedlich sind. 
Beispielsweise sind bei der Datei auf der externen SSD 130 Bytes 
abweichend, bei der Datei auf der externen HDD 68 Bytes. Interessant: 
immer nur das LSB ist abweichend.

In einem Punkt muss ich revidieren: die Datei auf dem NAS ist identisch 
zur Ausgangsdatei.

Scheint mir, dass hier über USB ziemlich viel Müll passiert.

Thorsten

von Thorsten .. (tms320)


Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Das Packprogramm 7z bietet unter Windows eine Erweiterung für den
> Dateimanager von Windows an, das Prüfsummen von Dateien erstellen und
> anzeigen kann.

Genau das habe ich benutzt, trotzdem Danke. Wegen Kabel: 
unwahrscheinlich, sind zwei verschiedene Kabel. Die SSD ist über 20cm 
direkt ans Mainboard angeschlossen, die HDD vielleicht über 50cm 
ebenfalls direkt ans Mainboard.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
Thorsten .. schrieb:
> Beispielsweise sind bei der Datei auf der externen SSD 130 Bytes
> abweichend, bei der Datei auf der externen HDD 68 Bytes. Interessant:
> immer nur das LSB ist abweichend.

Ich würde mal einen Memtest laufen lassen. RAM-Fehler können durchaus zu 
sowas führen, auch wenn der Rechner sonst normal zu funktionieren 
scheint.

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Thorsten .. schrieb:
> Scheint mir, dass hier über USB ziemlich viel Müll passiert.

Dank CRC sehr unwahrscheinlich. Ich würde an Deiner Stelle mit dem 
Rechner nichts mehr machen, ohne einen vernünftigen Speichertest 
(memtest86+) gefahren zu haben.

von Larry (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Dank CRC sehr unwahrscheinlich.

Scheinbar interessieren sich die Geraete nicht sonderlich
fuer die Pruefsumme. Ich kenne Datenkorruption beim Kopieren
ueber USB auch, also von USB-Geraet auf USB-Geraet.
Abhilfe hat bei mir ein 2. USB-Adapter geschaffen, an dem das
Ziellaufwerk betrieben wurde.

von Manfred (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hmmm schrieb:
>> Scheint mir, dass hier über USB ziemlich viel Müll passiert.
> Dank CRC sehr unwahrscheinlich.

Theoretisch vielleicht, in der Praxis real vorhanden.

Ich habe eine externe HD, wo es unter Windows_7 und USB_3 des öfteren 
korrupte Files gab. Schreibe ich mit XP und USB_2, passiert das nicht.

Ich schleppe hier viele Checksumfiles herum, erzeugt mit ExactFile, um 
das zu erkennen.

von Jens M. (schuchkleisser)


Bewertung
0 lesenswert
nicht lesenswert
Kopiere mit TeraCopy und nutze die CRC-Funktion.
Damit habe ich 3-, wenn nicht schon 4-stellige TBytes über USB2 und 3 
auf Win XP, 7 und 10 auf etlichen PCs übertragen, ohne das es Fehler 
gab.

Wie Kompass, Herr Kapitän?
Hab ich Glück?
Sind meine Billigst-ebay-Kabel doch besser als gedacht?

von oszi40 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Thorsten .. schrieb:
> Habe die Datei nun also auf 4 verschiedenen Laufwerken vorliegen.

Dann kopiere die fraglichen Dateien doch mal zum Test mehrfach auf ein 
Laufwerk. Es könnte evtl. eine aktive Systemdatei dabei sein, die sich 
verändert hat?

von Mathias A. (mrdelphi)


Bewertung
0 lesenswert
nicht lesenswert
Thorsten .. schrieb:
> Es ist tatsächlich so, dass die Datein unterschiedlich sind.
> Beispielsweise sind bei der Datei auf der externen SSD 130 Bytes
> abweichend, bei der Datei auf der externen HDD 68 Bytes. Interessant:
> immer nur das LSB ist abweichend.
>
> In einem Punkt muss ich revidieren: die Datei auf dem NAS ist identisch
> zur Ausgangsdatei.
>
> Scheint mir, dass hier über USB ziemlich viel Müll passiert.
>
> Thorsten

Wow interessant! Um genau sowas zu erkennen mache ich auch 
gewohnheitsmäßig Vergleiche nach dem Kopieren, sei es per Checksum oder 
byteweise -- aber an tatsächlich aufgetretene Fehler kann ich mich jetzt 
nicht erinnern, außer es wurden Dateien versehentlich während oder nach 
dem Kopieren durch Software modifiziert. Das zeigt also es ist absolut 
sinnvoll, diese Vergleiche zu machen auch wenn Fehler extrem selten 
sind. Es sei denn die Daten sind unwichtig, aber warum sollte man sie 
dann überhaupt kopieren ;-)


Hattest Du bei dem System früher schon mal Probleme mit USB bemerkt? 
Erstaunlich finde ich dass es offenbar nur Nutzdaten betrifft, wenn in 
den Steuerdaten Bits kippen dürfte das ja schnell zu Fehlermeldungen 
führen.

Nachtrag, ok es kann sein dass Steuerdaten per CRC o.ä. geschützt sind 
aber die Payload nicht, dann könnte genau das passieren. Weiß jetzt 
nicht ob das bei USB so ist.

: Bearbeitet durch User
von Mister A. (mratix)


Bewertung
-1 lesenswert
nicht lesenswert
Das ist ja ein interessanter Fehler.

Ich tippe zunächst nicht auf das USB Kabel, eher auf den 
USB2SATA-Converter/Controller im Case.

Leider schreibst du nichts zum verwendeten Case. Ich gehe mal davon aus, 
dass es kein dieser billigst Direktadapter (zum aufstecken mit USB 
Kabel+Stecker) ist.

Nach dem der Kopiervorgang anscheinend durchgelaufen ist, kein Fehler 
(abgebrochen oder unvollständig) zurückgemeldet wurde, schließt es 
wiederum den Controller im Case aus. Das Case hat keinen Cache daher 
muss das Betriebssystem auf Auslieferung warten. Beim unmount/Auswerfen 
wird ja nochmals gesynced. Bleibt höchstens nur der Schreibcache der 
HDD. Der wiederum produziert nicht ein paar fehlende Bytes und sauber 
geschlossene Files.

Die paar zusätzlichen Bytes riechen ganz stark nach einer Zecke :)
So etwas wie der gute alte Parity-Boot-B, falls er auf NTFS nissten 
kann.

: Bearbeitet durch User
von Mathias A. (mrdelphi)


Bewertung
0 lesenswert
nicht lesenswert
@mratix: Thorsten schrieb dass es bei zwei USB-Geräten Fehler gab, und 
sie waren mit unterschiedlichen Kabeln an unterschiedlichen Ports am 
Mainboard angeschlossen.

D.h. es kann eigentlich nur am Mainboard liegen. Entweder Hardware 
defekt, oder vielleicht auch nur ein Fehler im Treiber...

von oszi40 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mathias A. schrieb:
> D.h. es kann eigentlich nur am Mainboard liegen. Entweder Hardware
> defekt, oder vielleicht auch nur ein Fehler im Treiber...

In zweifelhaften Fällen sollte man zusätzlich einen längeren Ramtest 
laufen lassen. z.B. memtest86 
https://www.heise.de/download/product/memtest86-41271

von Nano (Gast)


Bewertung
1 lesenswert
nicht lesenswert
oszi40 schrieb:
> Mathias A. schrieb:
>> D.h. es kann eigentlich nur am Mainboard liegen. Entweder Hardware
>> defekt, oder vielleicht auch nur ein Fehler im Treiber...
>
> In zweifelhaften Fällen sollte man zusätzlich einen längeren Ramtest
> laufen lassen. z.B. memtest86
> https://www.heise.de/download/product/memtest86-41271

Der Link verweist auf Memtest86+.
Dieser Open Source Fork wird nicht mehr weiterentwickelt und es kann 
sein, dass er mit modernem Speicher keine zuverlässigen Ergebnisse mehr 
liefert.

von Thorsten .. (tms320)


Bewertung
1 lesenswert
nicht lesenswert
Danke erst mal an alle für die vielen Hinweise!

Hier ein kurzes Update.

Hab Memtest heute Vormittag über 3h laufen lassen, keine Fehler. Hab 
dann auch noch mal Memtest86+ einen Durchlauf machen lassen, auch kein 
Fehler.

Hab dann die externe HDD und die externe SSD an einem USB2-Port des 
Mainboards angeschlossen, auch hier sind die Dateien Unterschiedlich. 
Also gleiches Problem.

Habe dann mal ein Verzeichnis auf der im Rechner eingebauten HDD mit 
Bildern (ca. 6000 Dateien, Dateigröße jeweils so 10-30MB) durch 
ExactFile (danke für den Tipp, gutes Tool!) gejagt. Gleiches mit der 1:1 
Kopie dieses Verzeichnisses auf der externen HDD. Meine Güte...jede 
Menge Dateien unterschiedlich.

Fazit soweit erst mal: die Integrität der auf der externen HDD sowie SSD 
gespeicherten Daten muss angezweifelt werden bzw. die Daten sind 
eigentlich nutzlos. Wenn bei einem JPEG mal ein Byte kippt, dürfte nicht 
viel machen. Bei einem Image eines Systemlaufwerks natürlich große 
Katastrophe.

Ich glaube jetzt auch, dass das Mainboard einen Defekt hat. Ich denke, 
ich werde mir mal eine PCIE Karte mit USB3.1-Ports bestellen und testen. 
Wäre halt erst mal günstiger als ein neues Mainboard.

Kurz noch zum System: Asus TUF Z370-PRO Mainboard mit i7-8700 und 16GB 
DDR4 von Corsair. Alles zusammen keine 2 Jahre alt. Ich hatte am Anfang 
große Probleme mit dem System insbesondere mit Windows 10. Musste einige 
Male ein Image zurückspielen und dabei kam es immer wieder mal zu einem 
Fehler von wegen dass die Imagedatei beschädigt sei. Anfangs bei Acronis 
True Image, später dann auch bei Macrium Reflect.

Grüße

Thorsten

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Thorsten .. schrieb:
> Asus TUF Z370-PRO Mainboard mit i7-8700 und 16GB DDR4 von Corsair.

Irgendwelche Basteleien wie Overclocking?

von Mathias A. (mrdelphi)


Bewertung
0 lesenswert
nicht lesenswert
Thorsten .. schrieb:
> Alles zusammen keine 2 Jahre alt. Ich hatte am Anfang
> große Probleme mit dem System insbesondere mit Windows 10. Musste einige
> Male ein Image zurückspielen und dabei kam es immer wieder mal zu einem
> Fehler von wegen dass die Imagedatei beschädigt sei. Anfangs bei Acronis
> True Image, später dann auch bei Macrium Reflect.

War dabei auch USB im Spiel? Oder alles rein auf den internen Platten?

von oszi40 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Thorsten .. schrieb:
> Musste einige
> Male ein Image zurückspielen und dabei kam es immer wieder mal zu einem
> Fehler von wegen dass die Imagedatei beschädigt sei.

Wenn der RAM angeblich ok ist, würde ich nun die SMART-Werte der 
Festplatten genauer ansehen. Evtl. ist die System-HD krank? 
CristalDiskinfo?

Thorsten .. schrieb:
> Hab nun mit Macrium Reflect benutzt
Dann würde auch mal ein anderes Programm wie Clonezilla von CD/USB 
testen um sicher zu sein, dass nicht ein SW-Fehler die Ursache ist.

von Klaus P. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Nano schrieb:
> Das Packprogramm 7z bietet unter Windows eine Erweiterung für den
> Dateimanager von Windows an, das Prüfsummen von Dateien erstellen und
> anzeigen kann.
> Ansonsten kann man auch git für Windows installieren, das liefert dann
> eine Basherweiterung mit und in der sind die üblichen Programme wie
> sha256sum zugänglich.

Man braucht nichts zu installieren, die Powershell enthält dafür den 
Befehl "Get-FileHash".

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Klaus P. schrieb:
> Man braucht nichts zu installieren, die Powershell enthält dafür den
> Befehl "Get-FileHash".

Danke für den Tipp, gut zu wissen, ich nutze die Powershell kaum.
Ich kenne aus der Win2K und WinXP Zeit von Windows noch fciv, aber das 
kann nur MD5 und SHA-1 Checksummen und musste extra von Microsoft 
downgeladen werden.
https://www.microsoft.com/en-us/download/details.aspx?id=11533

Ich habe daher früher immer von GNUWin32 die coreutils installiert, da 
war md5sum dabei, was ich auch unter Linux nutze. Heute kriege ich das 
aber auch über die Installation von git für Windows und das brauche ich 
ohnehin und sha256sum ist auch gleich dabei.

Wenn die Powershell das inzwischen auch kann, dann finde ich das aber 
auf jeden Fall gut, das hilft mir dann bei Neuinstallationen wenn noch 
kein sha256sum & Co installiert ist.

7z kommt bei mir ohnehin drauf und die Tatsache, dass es sich per GUI 
bedienen lässt, dürfte zumindest Einsteigern entgegen kommen, daher 
erwähne ich das immer. Ich selbst nutze eher sha256sum in der Shell.

von YA-Leser (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Neuere Windowsversion (NICHT WIN7) können noch mit dem onboard tool 
certutil Hashes von Dateien erstellen.

von oszi40 (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
YA-Leser schrieb:
> certutil
certutil v -?  certutil -hashfile Datei

Trotzdem sollte der TO seine wunderliche Datei MEHRFACH auf dem GLEICHEN 
Datenträger schreiben und das Testergebnis vergleichen.
Evtl. prüft er ja veränderliche Werte?? Wie z.B. time >> irgendwas.txt

von Thorsten .. (tms320)


Bewertung
0 lesenswert
nicht lesenswert
Warum ist die Datei wunderlich? Ist eine ganz normale Imagedatei von 
einem Systemlaufwerk. Wenn ich die auf ein anderes Laufwerk kopiere, 
dann erwarte ich, dass die Checksumme über ihren Inhalt identisch ist. 
Und genau das ist eben nicht der Fall.

Hab jetzt mal ein aktuelles Live Linux gebootet und die "wunderliche" 
Datei auf die genannten externen Laufwerke kopiert; auch mehrfach auf 
das gleiche Laufwerk. Die Checksummen sind stets unterschiedlich. Also 
kein Treiber-Problem unter Windows.

Die Datei auf einen anderen modernen Rechner kopiert und von dort auf 
die externen Laufwerke => identische Checksummen, alles ok!

Somit hat der USB3 Controller auf meinem Mainboard offensichtlich eine 
Macke. Werde mir heute wohl mal ein neues MB bestellen.

Ich werde weiter berichten:)

Danke an alle!

Thorsten

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Thorsten .. schrieb:
> Somit hat der USB3 Controller auf meinem Mainboard offensichtlich eine
> Macke. Werde mir heute wohl mal ein neues MB bestellen.

Es gibt noch USB PCIe Karten. Die sind eventuell günstiger als ein ganz 
neues Mainboard.

von Thorsten .. (tms320)


Bewertung
0 lesenswert
nicht lesenswert
Hab jetzt noch mal paar Tests gemacht.

Problem bestand heute morgen wie beschrieben. Dann einen (von zwei) 
RAM-Riegel ausgebaut, dreimal Kopiervorgang durchgeführt (dazwischen 
jeweils Neustart), keine Fehler. RAM-Riegel getauscht, gleiche 
Kopieraktion, keine Fehler. Beide Riegel wieder eingebaut, keine Fehler. 
Vielleicht ein Kontaktproblem? Kann ich aber kaum glauben, denn das 
müsste sich doch an vielen Stellen im System auswirken. Jedenfalls 
funktioniert aktuell alles und ich werde erst mal keine neue Hardware 
kaufen. Irgendwie ist das alles sehr merkwürdig.

Gruß
Thorsten

von Jens M. (schuchkleisser)


Bewertung
0 lesenswert
nicht lesenswert
Wenn das RAM so defekt wäre, wäre Windows binnen Sekunden abgeschmiert.
Aber die mechanische Rumfuhrwerkerei hat evtl. ein schlecht gecrimptes 
Kabel richtig verbogen, einen oxidierten Stecker etwas saubergekratzt 
oder eine lose Lötstelle unter Spannung gesetzt, so das der 
USB-Controller jetzt erstmal wieder gut funktioniert.

von Schüler weiss alles besser (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Thorsten .. schrieb:
> Was meint ihr?
Dass die ganzen Ratschläge oben für die Tonne sind. RAM-Test - was für 
ein Bullshit.

Kabelproblem wird oft fälschlicheweis angenommen für die folgenden 
Ursachen:

Höchstwahrscheinlich:
Deine USB-Gehäuse haben als USB2SATA-Bridge Gurkenchips verbaut, der 
Grossteil diese Bridges taugt nix und hat je nach Hersteller und Serie 
diverse Macken. ASMedia sind noch am brauchbarsten. Kombichips mit USB 
und eSATA sind durchweg schrott. Sind getrennte Chips verbaut siehts 
anders aus, gibts aber sowieso kaum noch.
Manche Bridges kommen auch nur mit SSDs nicht zurecht, mit HDDs gibts 
keine Probleme.

Oft hilft schon UAS zu deaktivieren, das können sie fast alle nicht 
richtig, damit hat man schon ein Grossteil der Probleme vom Hals wenn 
man das deaktivert. Notfalls mit USB2 Speed betreiben.

Je nach Chip macht SMART Ärger, das Powsersaving am USB-Port, bekloppte 
Config des Bridgechips durch den Gehäusehersteller. Für manche Chips 
gibts das Tool zum Tweaken auch im Netz auf inoffiziellen Seiten, die 
Probleme lassen sich aber auch so umgehen wenn es an dem Chip liegt.

Ich würde die SSD ans Motherboard klemmen und nicht per USB kopieren, 
wenn es hier auch unterschiedliche Hashes gibt hast du das Problem ganz 
woanders.

von oszi40 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Thorsten .. schrieb:
> Beide Riegel wieder eingebaut, keine Fehler.

Ein vages Kontaktproblem oder RAM-Riegel vertauscht? Ein RAM-Fehler ist 
wie eine Socke mit Loch. Je nach Fuß ist das Loch woanders.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.