spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich finde die Idee mit den Hashes eigentlich ganz gut. Ich würde vielleicht sogar jede Datei in mehreren Blöcken hashen (1-4k). Die meisten Kollisionen werden wohl ohnehin durch die Größe der Datei ausgeschlossen werden können und von den übrigen die meisten über die ersten paaar gehashten Blöcke. Ich halte es für recht unwahrscheinlich, dass sich erst sehr weit hinten Kollisionen ergeben. Mit Block-Hashes und einem Indizierten File-Lookup-by-Length solltest Du Dir also viel Lese- und Vergleichs-Aufwand sparen können.
Mich würde trotzdem interessieren, ob git diff hilfreich ist in diesem Fall.

Hmm ihr habt schon gelesen, dass sich der Hash sehr wahrscheinlich immer unterscheiden wird, da in den Dokumenten immer die Metainformationen unterscheiden? Sprich man müsste den Block immer erst rausfiltern, wenn ich das richtig verstand.

Wenn er Glück hat, liegt der Meta-Block an einem festen Offset und man kann ihn einfach vor dem Hashing rausschneiden. Ansonsten den Ansatz von BlueCobold nutzen, also blockweise hashen.

Exactly, die Metadaten muss er ja offenbar sowieso rausfiltern, natürlich muss er das auch für's Hashen tun...

Die Sache ist: Wenn du dich nicht z.B. mit einem prozentualen Vergleich, den du z.B. ab 90% Übereinstimmung bzw. 10% Nichtübereinstimmung abbrechen kannst, zufrieden geben willst, musst rein prinzipiell sowieso die ganze Datei runterladen. Dann kannst du auch einfach die Metadaten rausfiltern und die Datei hashen...

Zitat von »Architekt«

Ich hätte nur gerne den Umstand vermieden, immer gleich den ganzen Datei-Content zu laden..

Eben darum die Sache mit den Hashes. Da musst du jede Datei nur einmal durchlesen, nämlich während du den Hash berechnest und dann nur noch die Hashes vergleichen. Idealerweise würde man den Hash gleich während dem Download der Datei mitberechnen...