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
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?
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?
Byteweise vergleichen ist eine gute Idee, bin ich jetzt gar nicht drauf gekommen:) Werde ich gleich mal machen.
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.
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
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.
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.
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.
> 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.
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.
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?
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?
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
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
@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...
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
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.
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
Thorsten .. schrieb: > Asus TUF Z370-PRO Mainboard mit i7-8700 und 16GB DDR4 von Corsair. Irgendwelche Basteleien wie Overclocking?
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?
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.
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".
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.
Neuere Windowsversion (NICHT WIN7) können noch mit dem onboard tool certutil Hashes von Dateien erstellen.
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
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
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.
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
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.
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.
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.