.: CheckIt! :.

[Chrissi91]

Name: .: CheckIt! :.

Version: 1.3

Beschreibung: Tool zum vergleichen 2er Dateien.

Hallo ,

ich habe eute mal ein kleines Tool programmiert, das es eröglicht, 2 Dateien zu vergleichen. Es ist sehr simpel und war eher ein Langeweilevertreib . Beim Fehlerreport muss ich mir noch etwas einfallen lassen, da das niemand verstehen wird, auch ich nicht. ^^ Über Vorschläge freue ich mich und über Kritik ebenfalls.

[Chrissi91]

Wenn ihr euch geeinigt habt, könnt ihr mir ja bescheid geben .

Zu dem Errorlog. Es heißt Fehlerreport ^^ .

Das ist in Version 1.0. Es ist das Memo! Mauszeiger raufhalten und es kommt ein Label neben der Maus (Hint). Da steht Fehlerreport. Keine Ahnung, was er anzeigt ... all das, was in blockread als variableb drinsteht. da überleg ich mir noch was. denkt daran, dass ihr es mit einem, nnja, sagen wir Anfänger , zu tun habt. Ich brauche ja nicht die schnellste variante bei den hashwerten eine etwas einfachere tuts am anfang auch ^^

[ichbins]

Wir haben uns noch nicht geeinigt
werden es wohl auch nie tun

aber in version 1.1 kommt die Meldung mit dem Fehlerreport immer noch, obwohl es ihn nicht mehr gibt

[Chrissi91]

Änder ich in der nächsten Version. Kommt schon mal auf die ToDo - Liste. ^^ Will keiner dieses Hashzeug in mein Programmeinbauen ? Der würde auch den Code bekommen ^^

[St.Pauli]

Mit der MD5 - Unit wäre das:

Delphi-Quellcode:

IF (MD5Print(MD5File(Datei1)) <> MD5Print(MD5File(Datei2))) THEN
    Dateien sind ungleich!

[negaH]

Falls du nur zwei Dateien -> Datei A und Datei B vergleichen möchtest, dann benutzt du einen binären Direktvergleich.

Falls du aber zb. 16 Dateien mit jeweils 1 Mb alle untereinander vergleichen möchtest so benötigst du mit deiner Methode

16 * 16 komplette binäre Vergleiche die 16 * 16 * 1Mb = 256Mb Daten einlesen.

Mit der Hash Methode werden erstmal

16 * 1Mb = 16 Mb Daten eingelesen und ein Hash erzeugt, a 16 Bytes = 256 Bytes.
Dann werden diese 16 Hashs untereinander verglichen also 16 * 16 Vergleiche a 16 Bytes = 8192 Bytes Daten.
Da aber nun diese 16 Hash's schon bei ihrer Erzeugung in einer Sortierten Listen gespeichert werden, benötigt man effektiv nur durchschnittlich Ln2(16) * 16 = 64 Vergleiche mit ergo 1024 Bytes.

Insgesamt also

16 MByte bei 16 Dateien.

Deine Methode beackert 256 Mb Daten.
Meine Methode beackert 16 Mb Daten und die Hashvergleiche sind vernachlässigenbar.

Da der Hash 128 Bit groß ist, ist die Wahrscheinlichkeit das du 2 Dateien findest die gleiche Hashs bilden aber denoch unterschiedlich sind 1/2^64 groß. Du müsstest also im Durchschnitt 18446744073709551616 Dateien hashen um dann einmal gezwungen zu sein zwei Dateien wirklich binär vergleichen zu müssen.

Wenn also meine Methode mit 50% Wahrscheinlichkeit gezwungen sein soll bei einem Set aus 1 Mb großen Dateien einen tatsächlichen binären Vergleich durchzuführen, heist dies das insgesamt 16384 Yotabytes an Dateien gehasht werden um dann nochmals 2 Mb an Daten binär gegeneinadner vergleichen zu müssen.

16384 Yotabytes = 18446744073709551616 Megabytes.

Ich wüsste nicht das die Menschheit im gesammten 16384 Yotabytes an 1 Mb großen Dateien überhaupt speichern könnte.
Man kann also technisch fast mit 100 Prozent Sicherheit ausschließen das wenn zwei Dateien einen gleichen Hash erzeugen diese denoch unterschiedlich sind.

Mit deiner Methode würdest du bei gleicher Anzahl Dateien dann

302231454903657293676544 Yotabytes = 340282366920938463463374607431768211456 Megabytes vergleichen müssen.

Also schon ab minimal 3 Dateivergleichen, also Datei A wird mit Datei B und C verglichen wird meine Methode quadratisch schneller sein.

Nicht zu vernachlässigen ist der Punkt wie das Betriebsystem arbeiten muß wenn es im Vergleich entweder nur 1 Datei laden muß, einen Hash errechnet und danach eine zweite Datei laden mußund einen Hash errechnet, oder eben sofort zwei Dateien laden muß. Im ersteren Falle können die internen Caches der Festplatte/CPU etc. pp. mit einer Datei alleine ausgelastet werden, im zweiten Falle müssen diese Caches 2 Dateien speichern. Desweiteren ist di Wahscheinlichkeit sehr groß das eine Datei sequientiell auf der Festplatte Sektor für Sektor gespeichert wurde. Lädt man nur eine Datei sequientiell in den Speicher so werden die Kopfbewegungen der HD also optimaler sein, als wenn man abwechselnd immer Sektorweise auf 2 Dateien repositionieren muß.

Ach nochwas: vergiß den Vorschlag von St. Pauli und nimm einfach meine Unit. MD4 ist ca. doppelt so schnell wie MD5 und die geringeren Kollisionen des MD5's im Vergleich zum MD4 können, wie mit obigen Zahlen gezeigt, absolut vernachlässigt werden.

Wir benötigen hier keine perfekte kryptographische Sicherheit die MD5 rechtfertigen könnten, sondern nur eine sehr schnelle Methode um eine ausreichend gute Prüfsumme erzeugen zu können.

[edit]
Schaut man sich MD5File genauer an so erkennt man das dort mit Memory Mapped Files gearbeitet wird. In meiner Unit habe ich dies eben absichtloch nicht gemacht, und das aus gutem Grunde. Memory Mapped Files mappen wie in MD5File() demonstriert das komplette File in den Speicher, das hat hohe Priorität. Der dahinterliegende Mechanismus ist sehr kompliziert. Das führt dazu das bei großen Dateien die MMFs das OS zwingen Hauptspeicherresourcen anderer Anwendungen ins Swapfile auzulagern. Fazit: MMFs sind nicht dafür konstruiert wurden Dateien schnell zu laden, eine gebufferte Methode ist immer schneller.
[/edit]

Gruß Hagen

[Chrissi91]

Wieder mal was dazugelernt. Also, bei allen Bemühungen, ich weiß nicht wie ich das anstellen soll. negaH's Beitrag hat mich sehr überzeugt *einschliem* . Also, ich binde ie Unit ein, und was dann? Also. Ich lade mein Projekt und dann die Unit dazu, richtig? Danach weiß ich nicht weiter

Edit:

Für alle, die kein XP haben, den XP Style aber mögen, habe ich meine Version etwas verändert und einige Fehler ausgebessert. Die normale version änder ich auch noch ^^

[Chrissi91]

Also,

ich habe jetzt das Programm aktualisiert und einige Fehler berichtigt. Es gibt 2 Versionen, die sich nur im Layout unterscheiden:

CheckIt! XP:

Jeder, der kein XP hat, aber den XP - Style mag (so wie ich ), kann sich diese runterladen. Ich habe das Layout vom XP eingebaut, wenn auch nicht gerade sehr elegant.

CheckIt ST:

Hier wird der ganz normale Windows - Style verwendet. Allerdings ist ein XP Manifest eingebaut. Als Hintergrund gibt es einen Rot - Gelb - Farbverlauf.

Es tut mir leid, wegen dem Doppelpost , aber ich dachte mir, eine neuere Version sollte man nicht in einem alten Beitrag erwähnen (alten Beitrag editieren), da dies sonst von einigen übersehen werden würde.

[dahead]

@chrissi:

speicher doch deine screenshots im jpeg oder png format. das kannst du soweit ich weiß sogar mit ms paint machen. dadurch wird die dateigröße um ein wesentliches geringer (ich würde dir irfanview empfehlen, mit dem kannst du auch relativ gut screenshots von fenstern machen (lassen)).

[St.Pauli]

Zitat von Chrissi91:

Wieder mal was dazugelernt. Also, bei allen Bemühungen, ich weiß nicht wie ich das anstellen soll. negaH's Beitrag hat mich sehr überzeugt *einschliem* . Also, ich binde ie Unit ein, und was dann? Also. Ich lade mein Projekt und dann die Unit dazu, richtig? Danach weiß ich nicht weiter

Öffne doch mal die Unit und schau dir die Funktionen an. Bei der Funktion HashFile bist du richtig^^ Du trägst die FileCompare-Unit in uses-Klausel ein. Dann einfach:

Delphi-Quellcode:

  IF (HashFile(Datei1) = HashFile(Datei2)) THEN
    Dateien sind gleich

@ dahead: Ja, wird von Paint unterstützt.

[Chrissi91]

Sorry, wenn ich mich jetzt blöd anstelle, aber bei mir funktioniert es nicht ganz:

Ich konnte die Unit erfolgreich unter Uses einbinden . Kompilieren lässt sich das Pogramm auch schon.

Wenn ich jetzt folgenden Code habe, meckert er:

Delphi-Quellcode:

AssignFile(datei1,edit1.text);
Reset(datei1, 1);
AssignFile(datei2,edit2.text);
Reset(datei2, 1);
 repeat
  if (HashFile(Datei1) <> HashFile(Datei2)) THEN
   begin
    label5.caption:=Inttostr(strtoint(label5.caption)+1);
   end;
 until eof(datei1) or eof(datei2);
closefile(datei1);
closefile(datei2);

[Error] Incompatible types: 'String' and 'file'

filetostr gibt es nicht, oder?