Eindeutiger Vergleich für große Dateien gesucht

[dahead]

Hallo,

ich habe folgendes problem:

ich verwende momentan noch den MD5 algorythmus zum überprüfen von dateien auf gleichheit. nun habe ich festgestellt (und gelesen), dass ab einer gewissen dateigröße (bei meinen beispiel dateien ab 1 gb) der hash-wert gleich ist, obwohl sich die dateigröße um mehrere mb unterscheidet.

damit ist dann natürlich nicht mehr verlässlich zu sagen, dass dateien gleich bzw. ungleich sind. ich könnte zwar noch prüfen ob die dateigröße gleich ist um dieses problem zu umgehen, doch halte ich diese lösung nicht für ideal.

nun habe ich statt md5 mal Tiger verwendet. dieser zeigt mir zwar auch bei dateien dieser größe unterschiedliche hash-werte für (unterschiedliche) dateien an, die bestimmung des hash-wertes dauert allerdings wesentlich länger (bei einem beispiel versuch ca. doppelt so lange).

in meinem beispielversuch habe ich die tiger 192 implementierung der hashlib verwendet.

zu meinen fragen:

1.) kennt jemand von euch einen anderen, sprich schnelleren hash-algorytmus kennt, der auch dateien (am besten) größer 4 gb einwandfrei identifizieren kann?
am besten wäre eine einzige unit, da ich nicht ein riesen package einbinden möchte.

2.) ist eine geschwindigkeitssteuerung technisch überhaupt umöglich?

3.) bis zu welcher dateigröße genau, identifiziert md5 und tiger eine datei eindeutig?

vielen dank für die mühe!

[WoGe]

Hallo,

ich verwende für ein ähnliches Problem Sha256.

Allerdings denke ich das, falls du beide zu vergleichende Dateien im direkten Zugriff hast, garkeinen HashCode berechnen solltest, sondern einen direkten Binären Vergleich. Der ist dann sehr viel schneller. Gleiche Dateigrösse natürlich vorausgesetzt.

mfg
wo

[dahead]

Hallo,

erstmal danke für deine antwort!

ich habe dazu allerdings noch ein paar fragen:

1.) was meinst du mit direkter zugriff?

2.) wie soll ich mir einen binären vergleich vorstellen? die datei byte für byte überprüfen?

3.) welche sha256 implementierung verwendest du?

[WoGe]

Zitat:

Zitat von dahead

1.) was meinst du mit direkter zugriff?

Von einem Rechner gleichzeitig zugreifen können, wie lokale Platten, DVD oder Netzwerk

Zitat:

Zitat von dahead

2.) wie soll ich mir einen binären vergleich vorstellen? die datei byte für byte überprüfen?

Ja, das ist der schnellste Weg Gleichheit herauszufinden!

Zitat:

Zitat von dahead

3.) welche sha256 implementierung verwendest du?

Diese:
DCPcrypt v2.0 written by David Barton ([e-mail])

Um was für Dateien handelt es sich eigenlich?

mfg
wo

[dahead]

ok, als das mit dem binären vergleich ist jetzt klar. ich werde mal versuchen das umzusetzen.

aber das mit dem direkten zugriff hab ich immer noch nicht verstanden.

ich schildere mal grob wie mein programm arbeitet, denke dann wird es evtl. klarer:

1.) es listet sämtliche dateien eines bestimmten verzeichnisses auf.
2.) es werden informationen zu den gefundenen dateien gesammelt (größe, name, verzeichnis name wird extrahiert, usw.).
3.) die dateien werden verglichen, sprich die checksumme erstellt (momentan mit der option entweder nur wenn die dateigröße gleich ist, oder jede datei mit jeder, egal wie groß).
4.) ergebnis wird angezeigt.

Zitat:

Um was für Dateien handelt es sich eigenlich?

eigentlich um alle, die der benutzer vorgibt. sinn soll es sein, doppelte dateien zu erkennen.

ps: wenn du dcpcrypt (in deinem programm) benutzt, vergleichst du dennoch die dateien (im selben programm) binär? wahrscheinlich nicht, oder?

[WoGe]

Zitat:

Zitat von dahead

ps: wenn du dcpcrypt (in deinem programm) benutzt, vergleichst du dennoch die dateien (im selben programm) binär? wahrscheinlich nicht, oder?

Nein, ich stopfe Dateien von 0 - 100 MB im Schnitt 1MB in eine Datenbank. Um Sicherzustellen das ich keine doppelten einspeichere, berechne ich vorher den Hash und speichere den auch mit ab.
Dieses Verfahren hat sich bei zur Zeit ca 30.000 Einträgen als sehr sicher erwiesen.

gruss wo

[bigg]

Wie lang darf die Nachrichtengröße bei MD5 sein?

Laut Wikipedia liegt SHA-1 bei 2^64 Bit.
18446744073709551616 Bit
2305843009213693952 Byte
2251799813685248 KB
2199023255552 MB
2147483648 GB
(Bei weiteren Zahlen leidet leider meine Vorstellungskraft)

Also sollte SHA-1 doch locker reichen, oder :gruebel:
Alles ohne Gewähr. (Schreibt man das jetzt nicht seit neustem mit e anstatt ä)

[dahead]

@WoGe:

ok, aber ich denke in meinem fall wäre das dann wohl nicht ideal, da ich jede datei mit jeder vergleichen muss, sprich eine relativ große schleife habe. ich denke da wäre dann ein binärer vergleich wohl doch nicht angebracht.

in deinem fall (falls ich das richtig verstanden habe) überprüfst du ja deine datenbank nur auf die _eine_ checksumme der _einen_ neu hinzuzufügenden datei. ich müsste jede checksumme mit allen anderen checksummen vergleichen.

ich werde den binären vergleich aber auf jeden fall noch testen (bezüglich der geschwindigkeit).

--

@bigg:

ähm, wenn die werte stimmen, ist das wohl war. ich kenne zwar sha, ging aber davon aus, dass es eben nicht für solch große dateien geeignet ist. keine ahnung wo ich das gelesen habe. naja, auch das werde ich mal testen.

--

also erstmal danke euch beiden für die hilfe. ich melde mich wieder, wenn ich ergebnisse oder probleme habe. danke!

[dahead]

@bigg:

Zitat:

Alles ohne Gewähr. (Schreibt man das jetzt nicht seit neustem mit e anstatt ä)

meinst du das ernst? falls ja, was ist dann mit dem schießgewehr (schönes wort)?

[NicoDE]

Zitat:

Zitat von dahead

ich müsste jede checksumme mit allen anderen checksummen vergleichen.

Du Suche zu optimieren ist ein anderes Problem. Sortierte Listen könnten die Suche deutlich beschleunigen...

Zitat:

Zitat von dahead

ich werde den binären vergleich aber auf jeden fall noch testen (bezüglich der geschwindigkeit).

Um einen binären Vergleich kommt nicht herum wenn man die Aussage treffen will, dass die Dateien identisch sind.
Die Prüfsummen sind nur vorberechnete Entscheidungen (wenn die Prüfsummen nicht gleich sind, dann können die enthaltenen Daten auch nicht identisch sein - dies lässt aber keinen Umkehrschluss zu).

[bigg]

@dahead:
natürlich nicht, war nur ne blöde anspielung auf die neue rechtschreibung, die nun in fast allen bundesländern anerkannt ist :cry:

@nico:

Zitat:

...dies lässt aber keinen Umkehrschluss zu

Inwiefern? Könntest du deine Aussage näher erläutern?

[nailor]

wenn der hashwert gleich ist, sind die dateien nicht sicher gleich. mit der chance von 1 zu "'The Matrix' hat in allen Belangen Recht" könnten die dateien auch grundverschieden sein. oder sich in dem einen wichtigen byte der datei unterscheiden... oder oder oder...

[NicoDE]

Zitat:

Zitat von bigg

Könntest du deine Aussage näher erläutern?

Wenn die Prüfsummen gleich sind, müssen die Daten nicht identisch sein.

[mschaefer]

Moin moin,

also eins ist sicher, der binäre Vergleich ist relativ fehlerfrei zu programmieren. Mach für jede Datei einem Stream auf und lasse diese Byteweise durchlaufen. Jede Datei hat am Anfang eine gleiche Kennungs-Id (sagen wir zunächst 1). Unterscheidet sich eine Datei bekommt diese dann die nächste freie ID (hier:2) als zweite Variante. Eine weitere gleiche Datei in Variante 2 bekommt dann ebenfalls die 2. Da ein Stream bei grossen Dateien nicht die ganze Datei auf einmal einliset, ist das einfach und prinzipbedingt sicher.

Grüße // Martin

[bigg]

Das sehe ich auch so, aber habt ihr schonmal eine Kollision in einem der oben genannten Hash-Algos gefunden oder kennt ihr Seiten, die sich näher mit dieser Problematik auseinandersetzen?

[dahead]

Zitat:

oder kennt ihr Seiten, die sich näher mit dieser Problematik auseinandersetzen?

die hab ich vorhin z. b. entdeckt:

http://www.schneier.com/blog/archive...a1_broken.html

bzw. auf wikipedia gibt es auch infos zu den algorythmen:

http://de.wikipedia.org/wiki/Sicherer_Hash-Algorithmus

@mschaefer: ja, so wollte ich das auch angehen. bin noch am überlegen, wie ich das am besten in mein programm einbaue.

@all: danke für die zahlreichen antworten!

[mschaefer]

Moin, moin,

also würde mir da einen Treeview nehmen und in der Wurzel das Vergleichsdatum einsetzten. In der nächsten Hierachie die gefundenen Varianten und in der hierachie darunter die Dateinamen. Damit hat man dann einen AdHoc-Überblick.

Grüße // Martin

[dahead]

@mschaefer:

ja, das war jetzt nicht so gemeint, dass ich nicht weiß wie. die frage ist eher, wie ich das am besten in mein bestehendes programm einbaue. da muss ich noch eine geeignete möglichkeit finden.

am übersichtlichsten fände ich übrigens folgende struktur:

.........[ausgewählter ordner a]
.........|
.........`-> Datum (oder Hash) x
............ |
............ '-> Datei 1
............ '-> Datei 2
.........`-> Datum (oder Hash) y

.........[ausgewählter ordner B]
.........|
.........`-> Datum (oder Hash) x
............ |
............ '-> Datei 1
............ '-> Datei 2
.........`-> Datum (oder Hash) y

in der anlage ein screenshot, wie es bisher (md5) aussah. da sieht man auch das problem, was ich im aller ersten post ansprach.

wenn ich soweit bin und probleme haben sollte, mache ich besser einen neuen thread dazu auf. dennoch danke für den hinweis.

[mschaefer]

Moin, moin,

Mögen die Fachleute sich gerne melden, aber ich habe mal gelernt, das Hash-Algorithmen etwas für die Ablagevon Daten in Dateien mit wenigen aber gestreut liegenden Werten verwendet werden. Deine Dateien sind aber 100% gefüllt und damit ist der Hashwert kein geeignetes Instument für einen vollständigen Dateivergleich. Wenn es anders wäre hätten wir deutlich bessere Packprogramme zur Verfügung. Dein Beispiel belegt die Theorie - Gut so!
Hm wohl Zeit den Titel zu ändern.

Grüße // Martin



PS: Eigentlich kannst Du Deine Aufteilung beibehalten, Du mußt nur ein Feld "Varainte x" einbauen. Dafür kannst Du den Hashwert herausnehmen.

[dahead]

@mschaefer:

falls du mir damit sagen willst, dass man um dateien eindeutig identifizieren zu können, um einen binären vergleich des inhalts nicht umhinkommt, so ist das klar. das hat mir bereits WoGe sowie NiceDe gesagt.

allerdings benötige ich die hash-summe um einen schnelleren vergleich der einzelnen dateien durchführen zu können.

Zitat:

Dein Beispiel belegt die Theorie - Gut so! Hm wohl Zeit den Titel zu ändern.

was soll das heißen?

edit:

Zitat:

Varainte x

meinst du damit den algorythmus der checksumme?

[mschaefer]

Sorry,

wahrscheinlich ist meine Ausdrucksweise vor Feierabend etwas Zeitoptimiert. Mit Variante x meine ich die ID für eindeutige Dateien. Kann sein das unter ID 5 nur eine Datei liegt, da andere ungleich sind und unter ID 7 zwei oder drei Dateien oder..., da diese gleich sind. Würde dazu neigen den Titel in "Eindeutiger Vergleich für große Dateien gesucht.." oder ähnlich umzubenennen. Die Theorie legt einfach weniger variable Dateistrukturen zugrunde als Du Sie hast und Du hast mit Deinem Beispiel deutlich gemacht, dass für vollständig gefüllte Dateien das Verfahren wenig geeignet ist.

Eigentlich denke ich auch nicht, dass der Binärvergleich wirklich soviel langsamer ist !

Grüße // Martin

[dahead]

kein problem,

Zitat:

Würde dazu neigen den Titel in Eindeutiger Vergleich für große Dateien gescuht.. oder ähnlich umzubenennen.

werde ich machen!

Delphi-Quellcode:

Die Theorie legt einfach weniger variable Dateistrukturen zugrunde als Du Sie hast und Du hast mit Deinem Beispieldeutlich gemacht, dass für vollständig gefüllte Dateien das Verfahren wenig geeignet ist.

das ist richtig. in meinem beispiel-screenshot habe ich in meinem programm allerdings auch die option deaktiviert, die dateien vorher auf gleiche größe zu überprüfen. das habe ich nur getan, um feststellen zu können, ob auch dateien (beispielsweise 1 gb und größer) eindeutig identifiziert werden (das hätte ich eventuell noch erwähnen sollen).

da dies nicht der fall war, habe ich den thread hier überhaupt eröffnet.

wo du, WoGe und NicoDe recht habt ist, dass um eine datei eindeutig zu identifizieren ein binärer vergleich unabdingbar ist. diesen habe ich jetzt auch eingebaut.

ich prüfe die dateien allerdings immer noch vor dem überprüfen des binären inhalts auf gleiche checksummen, und davor auf gleiche dateigrößen. somit muss ich nicht jede einzelne datei binär überprüfen (wäre ja sinnlos, wenn die dateien unterschiedlich groß sind).

daher auch meine ursprungsfrage, welcher hash schneller als md5 ist.

also nochmals danke an alle für den hinweis und die hilfe!

[dahead]

ähm, wie benenne ich denn den thread um?

edit: hat sich erledigt, habs gefunden.

[Sharky]

Hai ihr lieben,

vor ab: Ich bin kein Kenner der gesamten "Hash-Systeme" (hier in der PP kenne ich nur einen der das angeblich kann)

Aber wenn ich das ganze richtig verstanden habe ist es doch so:
Eine MD5-Hash kennt maximal 2^128 Möglichkeiten

Wenn ich nun den MD5-Hash von allen [b8-Bit[/b] "Zeichen" ermittele habe ich per Definition nur 2^8 Mögliche Kombinationen.

Es gibt also nur eine berenzte Menge von Möglichkeiten. Die Auswahl von diesen ist Abhängig von der Menge der Eingangsmöglichkeiten?`

Wenn ich nun mehrere Dateien vergleichen möchte reicht es wenn ich ich von jeder Datei die ersten 2^128 Bit vergleiche.
Danach muss ich, bei einer Anzahl von 2^128 Datein, immer einen gleichdn Hash wert bekommen.

Aber ich kann nicht verstehen das dies bei Dateien ab einer bestimmten Größe häufer passiert als bei anderen?

Naja, wie schon gesagt: Der Profi für diese Fragen ist Hagen (sagt er ;-) )

Wenn ich eben total daneben war -> Sorry

[Chewie]

Zitat:

Zitat von mschaefer

Eigentlich denke ich auch nicht, dass der Binärvergleich wirklich soviel langsamer ist !

Wenn du nur 2 Dateien miteinander vergleichst, ist ein Binärvergleich wahrscheinlich schneller. Aber sobald eine Datei mit mehreren anderen und diese wiederum untereinander verglichen werden sollen, geht ein Hashwertvergleich schneller, da dieser ja pro Datei nur einmal berechnet werden muss.

[bigg]

Nochmal ein Link:
http://www.galileocomputing.de/openb...sel_24_003.htm

@dahead: MD4 ist nochmal schneller :)

[Flocke]

@Sharky: ja das war ein bisschen Unsinn :???:

2^N (z.B. 2^128) bedeutet, dass es genau so viele unterschiedliche Hashwerte gibt. Da es aber mehr als 2^N unterschiedliche Dateien gibt, nämlich unendlich viele, müssen bei 2^N+1 ja mindestens 2 Dateien den gleichen Hashwert haben.

So ein Vergleich über Hashwerte ist also immer nur eine notwendige Bedingung und keine hinreichende. Das bedeutet:

1. Wenn zwei Dateien einen unterschiedlichen Hashwert besitzen, dann haben sie auch einen unterschiedlichen Inhalt.

2. Wenn zwei Dateien den gleichen Hashwert haben, dann können sie gleich sein. Um es wirklich zu überprüfen, muss man die Dateien Bit für Bit vergleichen.

Und das gilt für jeden Hashcode! Egal ob MD5 oder SHA-1 oder was weiß ich.

[bigg]

@dahead:

Die Dateien die angeblich bei dir im Screenshot doppelt sind,
sehen für mich eher aus, als könnten sie nicht geöffnet werden :D

Zugriff auf Datei verweigert. *plonk*
Der markierte Hash ist eigentlich ein Initalisierungs-Wert,
das heißt ein Leer-String ergibt den gleichen Hash.

Prüf das mal mit FileDup :zwinker:

[negaH]

Es wurde ja schon alles relevante gesagt, aber trotzdem mal in komprimierter Form

1.) mit Hash's ermittelt man ob zwei gehashte Dateien gleich sein könnten, zu 100% sicher kann man sich aber erst sein wenn man sie binär Bit für Bit vergleicht

2.) da man also im Worstcase Bit für Bit zwei Dateien vergleichen muß wäre es dumpfsinnig NICHT die Dateigrößen auf Gleichheit als Indiz zu benutzen. Ergo: die Dateigröße sollte als erstes und primäres Unterscheidungsmerkmal herangezugen werden.

3.) der Performance Vorteil ergibt sich aus dem Arbeitsaufwand. Zuerst vergleicht man jeweils 32Bit mit 32Bit Dateigröße. Falls dort Gleichheit herrschen sollte vergleicht man 128Bit mit 128Bit Hashwert. Und erst bei Gleichheit vergleicht man nun die Dateien Bit für Bit. Das macht also 1/(2^32 * 2^128)=(1/2^160) an Trefferquote das man zwei Dateien auch wirklich binär vergleichen muß. Versuche mal 1/2^160 auszurechnen und überlege dir wie lange es dauert einen 160Bit Zähler der in die Sekunde 256 mal inkrementiert wird zum überlaufen zu bringen. (2^260 / 2^8) = 2^152 Sekunden ~ 180000000000000000000000000000000000000 Jahre !!) Man sieht das 160 Bit = 2^160 eine enorm große Zahl darstellt und somit die Wahrscheinlichkeit für zwei gleiche Hashwerte zu unterschiedlichen Dateien in der Realität sehr sehr gering sein wird, aber eben nicht unmöglich ist. In fakt gibt es theoretisch Unendlich-(2^160) viele Dateien die alle den gleichen Hashwert erzeugen müssen. Davon sind aber fast Undenlich viele Dateien unendliche Bits groß. D.h. die größte Masse an Dateien mit gleichem Hashwert sind so rießig groß das sie auf keinen Rechner gespeichert werden können.

4.) die so gesammelten Dateigrößen + Hashwerte sollten in einer datenbank sortiert gespeichert werden. Bei sagen wir mal 1024 so gesammelten Dateien in der DB benötigt man im Worstcase nur 12 Vergleiche von Dateigrößen + Hashwerten

5.) der Hashwert wird über die komplette Datei gezogen, NICHT nur über die ersten Bytes der Datei

6.) Da der hashwert nur 128 oder 256 Bits groß ist bedeutet das das zb. mit 1Mb großen Dateien exakt 2^(1Mb-256) Dateien gibt die den gleichen Hashwert erzeugen aber binär komplett unterschiedlich sind. Der Hash einer Datei, wie auch jede andere Prüfsumme ist also kein eineindeutiges Indiz für den Vergleich auf Gleichheit ! Sondern eher nur ein Indiz für Ungleichheit wenn die Hashwerte sich unterscheiden. Um so wichtiger ist es das man über die komplette Datei hasht.

7.) somit garantiert eine Hashfunktion das sie einen anderen Wert erzeugt wenn die Datei sich nur um 1 Bit unterscheidet. Sie garantiert aber nicht das zwei gleiche Hashwerte auch zweimal die gleiche Datei darstellt.

8.) Performancetechnisch sind die Hashfunktionen heutzutage schneller als jede Form eines direkten Binären Vergleiches. D.h. die Benutzung einer Hashfunktion ist absolut richtig wenn man einen performanten Vergleich erzielen möchte. Denn man produziert von einer neuen Datei nur einmal den Hash und vergleicht diesen dann mit 1000'enden anderen Hashwerten + Dateigrößen in der Datenbank. Das ist bei weitem viel weniger an Speicherzugriffen als alle diese Dateien binär bit für bit mit der neuen Datei zu vergleichen.

9.) ein 256Bit Algo. hat zwar viel weniger Redundanz als ein 128 Bit Algo, dafür sind die 256 Bit Algos durch die Bank weg aber auch langsammer, die Hashwerte benötigen 2x mehr an Speicherplatz und die Wahrscheinlichkeiten für Kollisionen mit unseren heutigen Dateien ist aber nicht um 2^128 vergleichbar größer. Ich würde also für so eine Aufgabe absolut den 128Bit MD4 Algo empfehlen. Er ist immer noch der schnellste seiner Art.

10.) bei einer solchen Aufgabe ist es wichtig sich darüber zu informieren wie die Wahrscheinlichkeiten der unterschiedlich auftretenden Dateien verteilen. Beispiel: in der DB sind 65535 Dateien gespeichert. Davon werden maximal aber nur 1-2 % auch die gleiche Dateigröße besitzen und davon hat KEINE den gleichen Hashwert. Wird nun eine neue Datei eingefügt so wird diese mit max. 1-2% der gespeicherten Dateigrößen übereinstimmmen und von diesen 2% wird mit sehr sehr geringer Wahscheinlichkeit 1 Datensatz den gleichen Hashwert besitzen.
Mit einer 128 Bit Hashfunktion kann man mal unsauber eine Pi*Daumen Abschätzung machen -> falls 2^128 Datensätze, also 2^128 verschiedene Dateien in der DB gespeichert würden so ist die wahrscheinlichkeit 100/(2^32) Prozent das man 1 Datensatz findet der mit dem neuen Datensatz übereinstimmen wird. Die 2^32 ist die Dateigröße die ebenfalls berücksichtigt werden sollte. Für diese riesige Datenbank von 2^128 Dateien heist dies das das Program sich eher auf eine hoch optimierte Datenbanksuche konzentrieren sollte da der eigentliche Dateivergleich sich in der Gesamtperformance fast garnicht auswirken wird.

Fazit: nehme MD4 mit 128Bit Hashwerten + Dateigröße in DB auf. Konzentriere dich darauf die richtige "Datenbank" zu finden statt sich mit der "besten" Hashfunktion Zeit zu vergeuden. In der Gesamtperformance wird es garantiert nicht die Hashfunktion sein die die meiste Zeit verbrauchen wird, eher die Suche in der DB.

Gruß Hagen

[dahead]

@bigg:

ich habe die im screenshot gezeigten dateien mit deinem programm mal getestet und er zeigt mir in der tat eine andere md5 checksumme an. also muss es wohl richtig sein, dass ich bei meinem test darauf keinen zugriff bekommen hatte (ich frage mich allerdings noch warum, muss ich noch prüfen).

was anderes: ich habe mir deinen source-code mal angesehen und festgestellt (evtl. auch übersehen, korrigier mich falls ich falsch liege), dass dein programm relativ zügig arbeitet. ich beziehe mich mal auf folgenden source auszug (hoffe das macht dir nichts aus):

Delphi-Quellcode:

Filter_FileSize;
FastScan;
Filter_ShortMD5;
LowScan;
Filter_LongMD5;

du prüfst die dateien allerdings nicht inhaltlich byte per byte, oder? (ich habe zumindest keine solche funktion auf die schnelle gefunden.)

edit: achja, danke für den link. der war auch sehr aufschlussreich. darin steht u.a. dass sha langsamer als md5 ist. bzw. auch, dass für md4 (mittlerweile auch für md5) kollisionen entdeckt wurden. dazu habe ich auch noch das hier gefunden: http://eprint.iacr.org/2004/199

@negaH:

vielen dank für deine mühe hier nochmal alles gründlich zusammenzufassen!

in der tat benötigt mein programm nicht die meißte zeit damit, den hash zu ermitteln. das geht auch bei md5 relativ zügig. das einzige zeit-problem ist der byte pro byte vergleich der kompletten filestreams.

[dahead]

ups. fehler.

[bigg]

Moin,

ich führe noch vor dem vollständigen Scan einen schnellen Scan durch.
Dabei lese ich die ersten 2 KB ein und bilde wiederum eine Prüfsumme, kommt es zu doppelten Summen überrpüfe ich die gesamte Datei.

[dahead]

hallo,

ja, das ist klar. allerdings prüfst du doch die komplette datei, indem du von der kompletten datei eine checksumme erstellst. aber wie hier in diesem thread ja festgestellt wurde, ist das nicht 100%ig eindeutig.

oder ist es schon zu spät für mich?

[bigg]

moin,

auch der komplette Scan stellt nicht sicher, das die Dateien identisch sind. :zwinker:

[dahead]

ja, genau das meine ich doch.

also prüfst du in deinem programm nicht byte per byte, oder?

[bigg]

Byte für Byte md5, eine andere Methode habe ich noch nicht eingebaut,
bin noch am optimieren.

[dahead]

ok, dann habe ich es verstanden. mich hätte nur die geschwindigkeit bei einer byte-per-byte analyse gewundert. bei mir rotieren da die festplatten köpfe, und bei deinem programm war er in einem bruchteil der zeit damit fertig.

[bigg]

Sind denn die Ergebnisse identisch oder gab es dabei abweichungen?

[dahead]

du meinst bei meinen tests nehme ich an?

naja, kann ich so nicht sagen, da ich nur diese eine datei kopiert und wieder eingefügt habe (ich habe leider nicht sonderlich viele dateien größer 1 gb auf meinem rechner liegen). der test ist also nicht aussagekräftig. ich wollte halt für den fall der fälle (kollision) doch einen byte-per-byte vergleich einbauen.

der startet (ähnlich wie bei dir) erst, wenn dateigröße und md5 hash gleich sind.

[negaH]

@dahead:

Zitat:

byte pro byte vergleich der kompletten filestreams

Du benutzt noch Filestreams ?
Suche mal nach "Memmory Mapped Files" und benutze diese neuere Technik des OS.
FileStreams sind schön und gut haben aber den Nachteil das sie auf eienr "älteren" Schnittstelle zum Datenträger basieren. Ich habe mit MMF's die ich readonly und in partitionen erzeuge bessere Performance erzielt.

Delphi-Quellcode:

type
  TMMF = class(TCustomMemoryStream) // readonly Memory Mapped File
  private
    FHandle: THandle;
    FMapping: THandle;
  public
    constructor Create(const FileName: String);
    destructor Destroy; override;
    function Write(const Buffer; Count: Longint): Longint; override;
  end;

constructor TMMF.Create(const FileName: String);
var
  P: Pointer;
  S: Integer;
begin
  FHandle := FileOpen(FileName, fmOpenRead or fmShareDenyWrite);
  if FHandle > 0 then
  begin
    S := GetFileSize(FHandle, nil);
    if S > 0 then
    begin
      FMapping := CreateFileMapping(FHandle, nil, PAGE_READONLY, 0, 0, nil);
      if FMapping <> 0 then
      begin
        P := MapViewOfFile(FMapping, FILE_MAP_READ, 0, 0, 0);
        if P <> nil then inherited SetPointer(P, S);
      end;
    end;
  end;
  inherited Create;
end;

destructor TMMF.Destroy;
begin
  if Memory <> nil then UnmapViewOfFile(Memory);
  if FMapping <> 0 then CloseHandle(FMapping);
  if FHandle <> 0 then CloseHandle(FHandle);
  inherited Destroy;
end;

function TMMF.Write(const Buffer; Count: Longint): Longint;
begin
  Result := 0; // we should raise a exception here, but useloss
end;

die obige quick&dirty Klasse kann als Ersatz für deinen Filestream dienen. Da sie von TCustomMemoryStream abgeleitet wurde kannst du über .Memory und .Size direkt per CompareMem() zwei Dateien vergleichen oder eben eine Hashfunktion drüberrutschen lassen.
Wie gesagt sie ist aber Quick&Dirty und man müsste noch einige Kleinigkeiten verbessern. Für deine ersten Versuche zum Vergleich der Performance zu TFileStream dürfte es aber reichen.

Gruß Hagen