Programm zum Vergleichen von Images (1TB) gesucht (Windows)

[INe5xIlium]

dass es nicht die Standby-List spammt wie z.B. 7-zip.

Was ist die Standby-List und warum spammt 7-zip da rein? (Ich nutze das noch nicht so lange)

Ergänzung (30. August 2025)

Jedes Hashprogramm mit Fortschrittanzeige erfüllt Deine Anforderungen. Ich finde HashTab gut, OpenHashTab wird wahrscheinlich genauso gut sein.

Teilweise. Ein Hash z.B. 7-Zip dauert nur 3 Stunden, weil die Festplatte teilweise über 200Mb/s macht.

ABER: Ein Programm, was auf so einen Vergleich ausgelegt ist, könnte schon früher abbrechen, sobald ein Unterschied gefunden wird.
Wenn ein Unterschied mit einer signifikanten Wahrscheinlichkeit zu erwarten ist und ich jede Datei nur einmal einem Vergleich unterziehe, würde es sich lohnen die Möglichkeit eines frühen Abbruchs bei Unterschied einzubauen.

Ich verstehe das Script von @Nolag noch nicht zu 100%. Die Zeilen 15-17 sehen aus, als würde man nur vollständige Blöcke testen und ich kenne die Parameter von dd noch nicht (gruselig, weil ich dd sonst nur zum Überschreiben von Dateien kenne ^^).
Aber abgesehen davon würde das Skript ziemlich genau das machen, was ich mir wünschen würde. Sogar mit Progress-Anzeige.

Vermutlich ist das ein Zeichen, dass ich mehr mit der bash machen sollte und mich mit den Standardprogrammen auseinander setzen muss. Das Skript von @kartoffelpü könnte es mit der gleichen Anpassung ja auch. Es ist zwar länger, aber Funktionen, die "read" im Namen haben, senken die Angst damit etwas zu überschreiben.

​

 

[Nolag]

Was ist die Standby-List und warum spammt 7-zip da rein? (Ich nutze das noch nicht so lange)

Das ist der Name für den Cache in Windows. Wenn man eine Prüfsumme auf einer riesigen Datei berechnet, macht es keinen Sinn das Lesen der Datei über den Cache laufen zu lassen. Das hat dann einfach zur Folge, dass alle bisherigen Daten aus dem Cache verdrängt werden und das Ende der riesigen Datei im Cache liegt. Das ist eigentlich nie sinnvoll, aber die meisten Programme inklusive 7-zip verhalten sich so.

Die Zeilen 15-17 sehen aus, als würde man nur vollständige Blöcke testen und ich kenne die Parameter von dd noch nicht (gruselig, weil ich dd sonst nur zum Überschreiben von Dateien kenne ^^).

Es wird auch der letzte Block der Datei überprüft, wenn er unvollständig ist. Die Zeilen 15-17 reduzieren den Zähler lediglich dann um eins, wenn die Dateigröße ganzzahlig durch die Blockgröße teilbar ist, weil der Zähler danach mit 0 beginnend verwendet wird und sonst über das Dateiende hinaus gelesen werden würde.
Man muss eigentlich keine Angst vor "dd" haben. Solange man keinen "of" parameter mit einem Raw-Device angibt, kann nichts passieren.

 

[Evil E-Lex]

ABER: Ein Programm, was auf so einen Vergleich ausgelegt ist, könnte schon früher abbrechen, sobald ein Unterschied gefunden wird.

So funktionieren kryptographische Hashfunktionen nicht. Der Hash berechnet sich immer aus dem gesamten Eingabedatenstrom. Viel wichtiger ist die Wahl der richtigen - weil schnellen - Hashfunktion. Der beliebte Standard SHA256 eignet sich nicht, weil das Verfahren gegenüber anderen Hashfunktionen langsam ist. Für selbst erzeugte Dateien genügt weiterhin MD5, weil die bekannten Schwächen von MD5 hier nicht ins Gewicht fallen. Schneller und sicherer als MD5 wäre BLAKE3. Wenn es eine nichtkrytpographische Hashfunktion sein soll geht auch xxhash.

 

[Nolag]

Natürlich kann man die MD5 auch inkrementell berechnen und vergleichen. Im folgenden Python Beispiel werden 1MB Blöcke gelesen und die MD5 beider Dateien inkrementell berechnet und nach jedem Block miteinander verglichen. Die MD5 wird am Ende nur ausgegeben, wenn beide Dateien die gleiche MD5 produziert haben. Die ausgegebene MD5 ist dann identisch mit der, die "md5sum" berechnet.

import hashlib
import sys

fname1 = sys.argv[1]
fname2 = sys.argv[2]
bufsize = 1024 * 1024

print ("Comparing files",  fname1,  "and",  fname2)
file_hash1 = hashlib.md5()
file_hash2 = hashlib.md5()
with open(fname1, "rb") as f1, open(fname2, "rb") as f2:
    chunk1 = f1.read(bufsize)
    chunk2 = f2.read(bufsize)
    while chunk1:
        file_hash1.update(chunk1)
        file_hash2.update(chunk2)
        chunk1 = f1.read(bufsize)
        chunk2 = f2.read(bufsize)
        if file_hash1.hexdigest() != file_hash2.hexdigest():
          print("Files are not equal!");
          sys.exit(1)
print("Files are equal: ",file_hash1.hexdigest());

 

[INe5xIlium]

So funktionieren kryptographische Hashfunktionen nicht. Der Hash berechnet sich immer aus dem gesamten Eingabedatenstrom.

"Der Hash" ist mir eigentlich egal, ich will die Dateien vergleichen, da muss ich nicht den Hash der Gesamtdatei haben.
Die Geschwindigkeit des Berechnens ist bei einer Hdd leider auch nicht das Problem.
Falls man mit einer Berechnung, wie von @Nolag vorgeschlagen, tatsächlich den Hash dazu bekommt, ist es natürlich noch besser.

Dass 7Zip den Cache kaputt macht, ist mir, solange ich den Pc nicht benutze, nicht so wichtig. Aber es ist gut zu wissen

 

[Evil E-Lex]

"Der Hash" ist mir eigentlich egal, ich will die Dateien vergleichen, da muss ich nicht den Hash der Gesamtdatei haben.

Na dann genügt ein Programm, dass Dateien byteweise vergleichen kann. Bei Windows gehört so etwas zum Lieferumfang: comp.exe

 

[INe5xIlium]

Wenn ich mir die Eigenschaften durchlese, klingt es, als könnte Winmerge darauf basieren. Ich lese nichts von einer Progress Bar und bei 1Tb Dateien von HDDs ist es wichtig, dass der Puffer groß genug ist.