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 von dahead:

1.) was meinst du mit direkter zugriff?

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

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 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 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
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 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 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).