Vorschläge, effizientes Hashing von Dateien für vergleich

[Empire Phoenix]

Hi, ich will mir gerade einen synchronisations tool bauen, und bin am überlegen, wie ich dateien am besten vergleichen kann. (last access modifier ist in diesem fall unfunktionabel da es mir um den wirklichen inhalt geht, und einige dateien periodisch neu generiert werden (aber meisten mit gleichen inhalt))

Möglich wäre jetzt mit java md5, sha und evtl. noch weitere (nicht sicher).

Die frage ist nun, welcher algorithmus wäre der sinnvollste, kryptografische stärken sind egal, es geht nur darum unterscheide in den dateien zu erkennen. Was würdet ihr vorschlagen?

 

[nillehammer]

Ich meine, md5 ist der schnellste, also nimm den.

 

[schalentier]

Git nimmt SHA-1, also wuerd ich das auch nehmen.

 

[SlaterB]

wie scharf sind überhaupt die Anforderungen?
selbst beim besten Hash, der zumindest eine kleinere Datenmenge als die (gezippte) Originaldatei erzeugt,
gibt es die Unsicherheit von Doppelten, und sei es mit Chance kleiner als 3x Lotto-Gewinn hintereinander,

genausogut könnte man dann auch eine einfache Quersumme bilden, vielleicht mit Doppelten-Chance ~1:1000

 

[Empire Phoenix]

Also generall ist das ganze nicht alzu kritisch, bei den dateien handelt es sich um assets für ein spiel (texturen,models,shader ect) die zwischen den entwicklern effizient geshart werden sollen.

(git bricht unter der datenmenge zusammen)
(svn hat seine eigenen probleme)

Derzeit liegt alles auf einen ftp, mit dem problem, dass durch die geänderten timestamps(wegen der generierung) entweder alles manuell gemacht werden muss (frei nach ich habe datei x geändert, ladet die mal neu)
oder man einfach über nacht alles runter/hoch lädt und dementsprechend viel nutzlosen traffic hat.

Generell ist geplant dateigröße und bytes + hash zu vergleichen, womit sich die überschneidungen eigentlich in grenzen halten sollten. (hoffentlich)

 

[schalentier]

Um wieviele Dateien gehts denn eigentlich? Und wie gross sind die so im Durchschnitt? Maximal?

Hatte bisher keine Probleme mit git, allerdings hab ich des bisher auch primaer fuer Sourcecode benutzt. Deshalb die Frage.

Ansonsten klingt das furchtbar dolle nach rsync.

 

[Empire Phoenix]

30gb aufwärts in unterscheidlich großen dateien;

-> Da braucht git ewig um lokale neu zu indexieren.

 

[schalentier]

Jup, 30gb als Binardaten wuerde ich auch nicht in ein VCS legen... egal in welches.

Probier doch mal rsync aus, das ist imho genau fuer deinen Usecase ausgelegt. Aber ich hab grad keine Ahnung, wie die bei rsync die Unterschiede-Erkennung von Dateien realisiert haben.