Und wer garantiert, dass das Lesen der geschriebenen Datei 100%ig funktioniert? Da könnte ja auch ein Fehler auftreten, so dass falsche Daten als korrekt interpretiert werden. 100%ige Sicherheit gibts nicht...

Meine 100% waren gerundet

Genau wie es die 100% beim vergleichen mit Hash-Werten sind. Wenn du das in Blöcke teilst, die einzelnen Blöcke beim lesen direkt hasht und die hashes vergleicht, sind das auch 100%.

idefix123456 hat folgendes geschrieben :

1. Lese von der Datei die ersten z.b. 50KB und schreibe sie in den RAM 2. Entnehme die 50KB aus dem RAM und schreibe sie auf das Ziellaufwerk (D:\) 3. Lese die gerade Geschriebenen 50KB vom Ziellaufwerk (D:\), und vergleiche mit den 50KB aus dem RAM 4.1 Beide Blöcke sind identisch, dann lese den Nächsten 50KB Block d.h. es beginnt wieder bei 1. 4.2 Beide Blöcke sind nicht identisch, dann entferne den letzten geschriebenen letzten 50KB Block von Laufwerk (D:\) und Kopiere diese Block erneut!

Hierbei hasst du nur ein Problem, wenn beim Lesen der Daten ein Fehler aufgetreten ist, also die Daten im RAM schon Fehlerhaft sind.

Es ist manchmal sinnvoller, alles "in einem Rutsch" zu vergleichen (Files oder Ordner):
WINDIFF
support.microsoft.com/kb/159214
ss64.com/nt/windiff.html
Dieser Artikel beschreibt, wie Sie das Dienstprogramm "Windiff.exe" verwenden. Dieses Programm ermöglicht den grafischen Vergleich des Inhalts zweier ASCII-Dateien oder zweier Ordner, die ASCII-Dateien enthalten, um zu überprüfen, ob sie identisch sind. Die Bytezahl und das Erstellungsdatum sind hierfür keine verlässlichen Anzeichen.

Manchmal kann es zu ungewöhnlichem Programmverhalten kommen, und Sie haben den Verdacht, dass eine Datei beschädigt ist oder dass zwei Dateien dieselbe Bytezahl, aber unterschiedliche Daten aufweisen. Daher möchten Sie sicherstellen, dass die beiden Dateien identisch sind. Wenn bei einer Datei der Verdacht auf Beschädigung besteht, ist die typische Lösung, die Datei von einer bekannten unversehrten Datei neu zu kopieren. Mit dieser Lösung kann das Problem möglicherweise behoben werden, allerdings wissen Sie dann nicht, ob die Originaldatei tatsächlich beschädigt war. Es kann durchaus wichtig sein, dies zu wissen, da die Beschädigung einer Datei auf ein zugrunde liegendes Netzwerk- oder Systemproblem hinweisen kann.
.
www.grigsoft.com/windiff_src.zip
www.grigsoft.com/windiff.zip

Boldar hat folgendes geschrieben :

Genau wie es die 100% beim vergleichen mit Hash-Werten sind. Wenn du das in Blöcke teilst, die einzelnen Blöcke beim lesen direkt hasht und die hashes vergleicht, sind das auch 100%.

Das ist schon nicht ganz das gleiche. Mit den Hashes hast du einen (ich sag dem jetzt mal) systematischen Fehlerfall der bereits in der Theorie vorkommt (unter Idealbedingungen). Der Restfehler in meiner Rechnung lässt sich praktisch nur noch durch Wiederholen ausschliessen und steht im Zusammenhang mit einem nichtdetektierbaren Hardwarefehler (oder einen Softwarefehler mit ähnlicher Wirkung).