.: CheckIt! :.

[Chrissi91]

Name: .: CheckIt! :.

Version: 1.3

Beschreibung: Tool zum vergleichen 2er Dateien.

Hallo :hi:,

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.

[ichbins]

Verbesserungsvorschläge:

- xpstyle
- mehr Platz. Bei Dateien mit Namen mit mehr als 10 Zeichen passt es nicht hin
- Zu was brauch ich dieses Memo? Dass es nach jedem einzelnen Byte aktualisiert wird beschleunigt die Aktion natürlich auch nicht

- bei mir hängt sich das Prog auf (zwei EXEn mit ~10 MB)




zum Schluss noch: zu was brauch ich das eigentlich? :gruebel: :stupid:

[Chrissi91]

Zitat:

Zitat von ichbins

xpstyle

Hab ich vergessen. Kommt aber gleich dazu.

Zitat:

Zitat von ichbins

mehr Platz. Bei Dateien mit Namen mit mehr als 10 Zeichen passt es nicht hin

mach ich gleich ^^

Zitat:

Zitat von ichbins

Zu was brauch ich dieses Memo? Dass es nach jedem einzelnen Byte aktualisiert wird beschleunigt die Aktion natürlich auch nicht

Naja. Wie schon gesagt. Mit dem Memo, da muss ich mir och was überlegen.

Zitat:

Zitat von ichbins

bei mir hängt sich das Prog auf (zwei EXEn mit ~10 MB)

Bei mir nicht. -auch bei großen Dateien nicht.

Zitat:

Zitat von ichbins

zum Schluss noch: zu was brauch ich das eigentlich? :gruebel: :stupid:

Das ist wie schon gesagt ein Zeitvertreib.Wozu du das brauchst weiß ich net :stupid: . Is für jemanden der es aber braucht.

[Luckie]

Zitat:

Zitat von Chrissi91

Zitat:

Zitat von ichbins

zum Schluss noch: zu was brauch ich das eigentlich? :gruebel: :stupid:

Das ist wie schon gesagt ein Zeitvertreib.Wozu du das brauchst weiß ich net :stupid: . Is für jemanden der es aber braucht.

Dann mach es zu mindest OpenSource, damit man wemfalls vom Code noch was hat.

[St.Pauli]

Hi,

ich find es irgendwie komisch wie verglichen wird? Die Unterschiede können ja manchmal ganz hilfreich sein, aber warum gibst du nicht einfach noch ne Option an, um per Hash zu vergleichen?

Bei mir hat dein Programm auch schon ein bisschen gebraucht um 2 Dateien (108 KB und 28 KB) zu vergleichen, und blieb auch eine Zeit lang hängen^^ Kann natürlich auch an meinem 1 MHZ Rechner hängen :cyclops:

Und zweitens - das Design. Der Formstyle als Dialog - besser wäre es doch ganz normal, wo man die Größe verändern kann, denn bei großen Dateinamen überlappen sich nämlich die Labels. Mit dem Memo weiss ich nichts anzufangen. :gruebel:

PS: Warum für ne neue Version ein neues Attachment?

[CReber]

Meine Fragen sind:

1.) Ist der Vergleich zuverlässig? (Ähnlich CRC32)
2.) Abhängig vom Dateinamen? (denke mal nicht^^)
3.) Der Source würde mich interessieren ;) Please make it Open-Source

[Chrissi91]

Zitat:

Zitat von CReber

Meine Fragen sind:

1.) Ist der Vergleich zuverlässig? (Ähnlich CRC32)
2.) Abhängig vom Dateinamen? (denke mal nicht^^)
3.) Der Source würde mich interessieren ;) Please make it Open-Source

1. Momentan lese ich die Datei ganz normal byteweise ein (blockread)
2. nein. nur spielerchen
3. denke schon, dass ich ihn demnächst posten werde, aber erst, wenn ich eine bessere methode zum vergliechen gefunden habe. ihr könnt mir ja mal ein paar vorschläge machen

[dahead]

Zitat:

Zitat von Chrissi91

3. denke schon, dass ich ihn demnächst posten werde, aber erst, wenn ich eine bessere methode zum vergliechen gefunden habe. ihr könnt mir ja mal ein paar vorschläge machen

kuck mal hier hat Hagen eine ganze Unit zu diesem Thema gepostet, inkl. CRC32 Vergleich.

[St.Pauli]

Ansonsten einfach selber machen. Entweder mittels der md5-Unit, oder dem DEC, etc... Wenn mich nicht alles täuscht hat sowohl das DEC als auch die MD5 Unit schon eine Funktion zum Hashen von Dateien.

[Chrissi91]

Zu der Unit von Hagen:

http://www.delphipraxis.net/internal...ct.php?t=60645 Das ist ja sehr interessant, nur kann ich damit nichts anfangen :cry: :xmas:

Das mit dem selber machen: Ich habe damit noch keinerlei Erfahrung. Wenn jemand gerne das Vergleichen mit einer Hashfunktion programmieren möchte, kann ich ihm den Code geben, damit er das dann einbinden und hier veröffentlichen kann. Ich glaube, wenn ich da jetzt ins Thema einsteige, bringt es mir nicht viel, da ich zur Zeit mit vielen für mich neuen Themen beschäftigt bin. :lol:

[malo]

:gruebel: Du musst doch nur Hagens Unit in dein Programm einbinden, und die Funktion "CompareFile" aufrufen. Gibt es da etwas nicht zu verstehen?

[ichbins]

Aber der md5- bzw. crc32-Vergleich ist NIE ganz sicher, da er nur den Hash der Datei einliest.

Lies die Datei am besten in 4096-Byte-Blöcken ein und vergleiche diese dann auf einen Schwung. Wenn Unterschiede auftreten kannst du diese per XOR feststellen.

Delphi-Quellcode:

var
  f1,f2:file of byte;
  buf1,buf2,diff:array[1..4096] of byte;
  read,i:integer;
begin
  ...
  while (not eof(f1)) and (not eof(f2)) do
  begin  
    fillchar(buf1,4096,#0);
    fillchar(buf2,4096,#0);
    blockread(f1,buf1,4096,x);
    blockread(f2,buf2,x);
    if buf1<>buf2 then
      //wie heisst nochmal der Befehl für Schleife fortsetzen :gruebel: //fällt mir jetzt nicht ein, also mach ichs anders.
    begin
      diff:=buf1 xor buf2;
      for i:=1 to 4096 do
        if diff[i]>0 then
          inc(differents);
    end;
end;

Wenn der Test fertig ist, kriege ich angezeigt: es gibt xxx Unterschiede. Weiteres entnehmen sie dem Errorlog.

Was für ein Errorlog :gruebel:

[Tubos]

Zitat:

Aber der md5- bzw. crc32-Vergleich ist NIE ganz sicher, da er nur den Hash der Datei einliest.

Hash-Algorithmen sind für sowas sicher genug ;)

[dahead]

das wurde zwar alles schon mal diskutiert aber:

erst
vergleichst du die dateigröße. wenn du zwei identische hast, dann
vergleichst du die erstellte checksumme der zwei dateien. wenn du zwei identische hast, dann
vergleichst du die beiden dateien byte für byte. wenn du zwei identische hast,
sind es auf jeden fall doppelte (sprich gleiche) dateien.

sinn dieser reihenfolge ist, dass du nicht sinnlos alle dateien mit allen dateien vergleichst.

als schneller hash empfiehlt sich md4, md5 und bei größeren dateien sha1.

[ichbins]

Aber die Checksumme zu erstellen dauert auch einige Zeit. Dazu muss auch die ganze Datei gelesen und verrechnet werden. Wieso also nicht gleich einen großen Vergleich machen?

[dahead]

ich bin kein fachmann für checksummen, aber soweit ich weiß, wird bei einer checksummen-erstellung NICHT die ganze datei eingelesen.

warum sollte sonst das erstellen einer checksumme zig-fach schneller sein, als der byte-per-byte vergleich einer sagen wir mal +4gb datei?

daher sind checksummen auch NICHT immer eindeutig.

edit: hier wurde alles erklärt.

[Tubos]

Es wird bestimmt die ganze Datei eingelesen, andernfalls könnte es sein dass ein Unterschied von ein paar Byte einen gleichen Hash ergibt - der Sinn von Hashfunktionen ist es, genau das zu verhindern!

[dahead]

wenn zwei dateien eine unterschiedliche Checksumme haben, sind sie definitiv unterschiedlich.

wenn sie den gleichen haben, ist allerdings nicht unbedingt das Gegenteil der Fall.

[Tubos]

Zitat:

wenn sie den gleichen hash haben, ist allerdings nicht unbedingt das Gegenteil der Fall.

Aber mit an Sicherheit grenzender Wahrscheinlichkeit

[ichbins]

Wenn aber sowieso die ganze Datei eingelesen wird kann man doch mit genauso hohem Tempo gleich eine Komplettprüfung vollziehen.

Du machst ja auch nicht beim Bestimmen ob eine Zahl eine Primzahl ist zuerst einen vielleicht-nicht-Primzahltext und testest erst dann, ob es eine Primzahl ist, wenn beide Tests dieselbe Dauer haben :roll:

[Chrissi91]

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

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 :twisted:

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

[Chrissi91]

Änder ich in der nächsten Version. Kommt schon mal auf die ToDo - Liste. ^^ Will keiner dieses Hashzeug in mein Programmeinbauen :mrgreen:? 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* :xmas: . Also, ich binde ie Unit ein, und was dann? :lol: Also. Ich lade mein Projekt und dann die Unit dazu, richtig? :lol: Danach weiß ich nicht weiter :mrgreen:

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 :lol:), kann sich diese runterladen. Ich habe das Layout vom XP eingebaut, wenn auch nicht gerade sehr elegant. :xmas:

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 :angel2: , 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. :shock: :cyclops:

[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:

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* :xmas: . Also, ich binde ie Unit ein, und was dann? :lol: Also. Ich lade mein Projekt und dann die Unit dazu, richtig? :lol: Danach weiß ich nicht weiter :mrgreen:

Ö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 :xmas:. Kompilieren lässt sich das Pogramm auch schon. :-D

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? :lol:

[St.Pauli]

Du must einfach nur den Pfad der Funktion übergeben, z.B. 'C:\Test.txt' - also als String :wink:

Edit:

Delphi-Quellcode:

...
VAR Datei1, Datei2 : string;
begin
Datei1 := 'C:\Test1.txt';
Datei2 := 'C:\Test2.txt';

IF (HashFile(Datei1) = HashFile(Datei2)) THEN
    ShowMessage('Dateien sind gleich');

[Chrissi91]

Großes Danke! Ich habe in Version 1.3 (1. Beitrag) nun die Hashfunktion von negaH eingebunden. Sie funktioniert! Ich werde den Source heute noch in der Rubrik Opensource veröffentlichen! Über weitere Kritik würde ich mich freuen. :-D

[ichbins]

Jetzt sieht das Fenster aber (bei mir) ein bisschen komisch aus:

- Ich kann es nicht mehr verschieben
- Es hat einen so komisch hässlichen Rahmen :?

http://www.michaelensslin.kilu.de/dp/images/checkit.jpg

(xp-Version)

[Chrissi91]

Vorher konntest du die XP - Version nicht verschieben. Aber jetzt, wenn du auf das Weiße auf der Form klickst (der Hintergrund mit dem schwarzen gestrichelten Rahmen), kannst du das Fenster verschieben. Ich weiß, es sieht hässlich aus, aber das ist das Neue (die Komponente) zum Verschieben. Aber gut, ich mache es wieder rückgängig.

[ichbins]

Du darfst nicht nur mit dem Hash überprüfen und dann schon behaupten die Dateien wären identisch!!!!

Wenn der Hash identisch ist, dann sind die Dateien HÖCHSTWAHRSCHEINLICH identisch (1: 2^128), aber eben nur höchstwahrscheinlich. Du musst sie also noch weiter überprüfen.

[Daniel G]

Zitat:

Zitat von ichbins

Du darfst nicht nur mit dem Hash überprüfen und dann schon behaupten die Dateien wären identisch!!!!

Wenn der Hash identisch ist, dann sind die Dateien HÖCHSTWAHRSCHEINLICH identisch (1: 2^128), aber eben nur höchstwahrscheinlich. Du musst sie also noch weiter überprüfen.

Du weißt aber schon, dass eine Wahrscheinlichkeit von 1 : 2^128 ziemlich unwahrscheinlich ist, oder?

[Chrissi91]

Ups, dann habe ich da wohl etwa Mistverstanden ...

Also, wenn der Hash nicht identisch ist, brauche ich nicht weiterzuprüfen, wenn er identisch ist, muss ich zusätzlich noch mal überprüfen, ob die Dateien wirklich identisch sind. Sozusagen eine Art, den PC nicht zu stark auszulasten, wenn es auf den ersten Blick (Hash) nicht identisch sein kann.

Sehe ich das so richtig?

[Daniel G]

Zitat:

Zitat von Chrissi91

Ups, dann habe ich da wohl etwa Mistverstanden ...

Also, wenn der Hash nicht identisch ist, brauche ich nicht weiterzuprüfen, wenn er identisch ist, muss ich zusätzlich noch mal überprüfen, ob die Dateien wirklich identisch sind. Sozusagen eine Art, den PC nicht zu stark auszulasten, wenn es auf den ersten Blick (Hash) nicht identisch sein kann.

Sehe ich das so richtig?

Joar, so gehts auch.

[ichbins]

wobei natürlich die Wahrscheinlichkeit dass es jetzt noch abweicht seeeeehr gering ist. WinRAR benutzt z.B. Hashes auch zur Archivüberprüfung.

[Chrissi91]

Hallo,
http://www.delphipraxis.net/internal...=476350#476350

Endlich ist das Projekt unter der Open - Source Sparte!