Für sowas nehme ich immer zuerst die Dateigröße und bei gleicher Dateigröße dann MD5. Gleiche MD5 und unterschiedliche Dateigröße heißt auch unterschiedliche Dateien. Eine fehlerhafte Erkennung von Gleichheit ist mir bei dieser Kombination noch nicht untergekommen.
Und wenn es definierte Dateitypen sind, wie eben PDF, JPG, PNG, ZIP, dann kannst Du anhand der ersten paar Byte der Dateien bei identischer Dateigröße und identischer MD5 noch damit prüfen, ob auch identischer Dateityp.
Oder andersherum: Dateigröße, Dateityp aus den ersten paar Byte ermitteln. Wenn die übereinstimmen, dann noch MD5 (dürfte dann auch schneller sein, als Dateigröße, MD5 und dann erst den Dateityp) und wenn das dann alles gleich ist noch binären Vergleich auf Dateiebene.
Die Wahrscheinlichkeit dann noch eine fehlerhaft Erkennung der Dateigleichheit zu "erwischen" dürfte deutlich geringer sein, als ein Sechser im Lotto
Ja, es geht erstmal nur um Binärdateien, also keine Textfiles mit Cr / CrLf Problem.
Der Dateivergleich ist eine Sache, aber nicht unbedingt mein Hauptproblem, sondern wie man das Ganze in eine optimale Dateistruktur giesst, also einen Folder/FileTree ähnlich dem Explorer zum Beispiel.
Ich sehe da möglicherweise zwei konkurrierende Pattern nebeneinander, einmal ein Dictionary für die Hashes um sehr schnell gleiche Dateien zu finden, und zum anderen z.B. eine TList als Baumstruktur, um die Files und Folderpfade abzubilden.
Das würde ich gerne ein eine einzige Klasse oder Struktur bauen, die alle Funktionen abdeckt, ohne große Fehlermöglichkeit und Redundanz.
Also Add/Get/Move/Delete (im Tree) aber auch Search (im Dictionary).
Es gibt vielleicht eine ganz andere, offensichtliche Lösung, aber im Moment sehe ich den Wald vor Bäumen nicht.
Klar, es ist wohl schon Freitag, daran muss es liegen
