Grosse Dateien vergleichen. Schnell, Sicher und Einfach ;)

[gee21]

Hallo Liebe Delphi Menschen ;)

Ich bin wieder einmal an einem neuen Projekt am schreiben und bin mir nicht so sicher was wohl im "Verhältniss" am besten / einfachsten / sinnvollsten ist!?

Situation:
- Auf einem Netzlaufwerk (SMB) kommen stündlich 2-3 neue Dateien hinzu. (ZIP Backup Dateien 50MB-50GB gross)
- Diese Dateien sollen in ein anderes Netzlaufwerk kopiert werden.
- Die Dateien sollen aber nicht überschrieben werden und es soll auch erkannt werden wenn eine Datei bereits existiert aber nicht mehr die selbe Datei ist
(Wir haben Angst das jemand eine Falsche Datei unter dem selben Namen abspeichert (überschreibt) und diese Falsche Datei würde sich dann durch unser ganzes Backup System durchschleichen und unsere gültigen alten Backups überschreiben).

Frage:
Wie kann man am besten Dateien vergleichen und ist dann einigermassen sicher das es sich immer noch um die selben (oder eben nicht) Dateien handelt?

Ich habe bereits versucht:
1- MD5 der Dateien auszulesen und zu vergleichen: Dauert aber bei 50GB Dateien sehr lange (ca 30min) und das Netzwerk (1 GBit/s Kabel) ist dann in dieser Zeit auch immer voll ausgelastet nur um die MD5 auszulesen. (Kann natürlich auch sein dass ich etwas falsch mache).

2- Die Dateigrössen vergleichen auf Byte Grösse. Hier weiss ich aber nicht wie sicher das am Schluss für dieses vorhaben ist.

Ich kenne noch die Möglichkeit:
3- Dateierstelldatum oder Änderungsdatum vergleichen. Auch hier weiss ich nicht wie sicher / sinnvoll das ist.


Die die mich kennen wissen ja bereits das ich immer relativ einfache Lösungen suche da ich immer noch ein ziemlich schwacher Delphi programmierer bin ;)

[Delphi.Narium]

Zuerst nur mal die Dateigröße vergleichen.

(Nur hingedaddelt)

Delphi-Quellcode:

function CompareFileSize(FileA, FileB : wideString) : Boolean;
var
  sr : TSearchRec;
  SizeA : Int64;
  SizeB : Int64;
begin
  if FindFirst(FileA, faAnyFile, sr ) = 0 then
    SizeA := Int64(sr.FindData.nFileSizeHigh) shl Int64(32) + Int64(sr.FindData.nFileSizeLow)
  else
    SizeA := -1;
  FindClose(sr);
  if FindFirst(FileB, faAnyFile, sr ) = 0 then
    SizeB := Int64(sr.FindData.nFileSizeHigh) shl Int64(32) + Int64(sr.FindData.nFileSizeLow)
  else
    SizeB := -2;
  FindClose(sr);
  Result := SizeA = SizeB;
end;

Nur wenn dabei gleich rauskommt, könnten die Dateien auch inhaltlich gleich sein. Erst dann kann mit der MD5-Checksumme (oder eine andere Checksumme) festgestellt werden, ob die Dateien nun wirklich gleich sind oder nicht.

Die halbe Stunde Aufwand für die MD5-Checksumme ist also nur erforderlich, wenn Dateien gleicher Größe vorliegen.

Alternative: Mit 'ner ZIP-Komponente die Dateilisten der ZIP-Dateien auslesen und deren Inhalt vergleichen. Auch das wäre nur erforderlich, wenn die Dateien über die gleiche Dateigröße verfügen.

[Uwe Raabe]

Zitat:

Zitat von gee21 (Beitrag 1505242)

Die die mich kennen wissen ja bereits das ich immer relativ einfache Lösungen suche da ich immer noch ein ziemlich schwacher Delphi programmierer bin ;)

In dem Fall würde ich dir empfehlen mal Syncovery anzuschauen.

[jaenicke]

Zitat:

Zitat von Delphi.Narium (Beitrag 1505245)

Nur wenn dabei gleich rauskommt, könnten die Dateien auch inhaltlich gleich sein. Erst dann kann mit der MD5-Checksumme (oder eine andere Checksumme) festgestellt werden, ob die Dateien nun wirklich gleich sind oder nicht.

Es macht keinen Sinn eine Checksumme über die komplette Datei zu erstellen um diese dann zu vergleichen. Erstens kann es dabei Kollisionen geben und zweitens müssen dafür beide Dateien komplett gelesen werden. Die Wahrscheinlichkeit, dass es - insbesondere bei einem falsch vergebenen Dateinamen - schon am Anfang der Dateien Unterschiede gibt, ist aber relativ hoch.

Deshalb macht es hier tatsächlich Sinn die Dateien von vorne an durchzugehen und direkt zu vergleichen, wenn die Dateigröße übereinstimmt.

Da Zip-Dateien meines Wissens kein zentrales Inhaltsverzeichnis haben, sondern alle Informationen in den lokalen Headern der einzelnen Dateien stehen, muss auch dafür viel gelesen werden, aber gerade bei größeren Dateien im Archiv könnte man einiges überspringen, so dass es auf diese Weise dennoch schneller gehen kann als wenn man alles liest.

[gee21]

Vielen Dank für eure schnellen Antworten.

Ich denke ich werde es zuerst gemäss dem Tipp von "Delphi.Narium" versuchen, weil ich schon angefangen habe mit dem Delphi Programm.

Falls es Probleme geben würde, würde ich es wohl mit dem "Syncovery" Tool versuchen. Es scheint mir als wäre dieses Tool ziemlich passend. Danke Uwe. :thumb:

LGrüsse aus der Schweiz.

[Delphi.Narium]

Zitat:

Zitat von jaenicke (Beitrag 1505249)

Zitat:

Zitat von Delphi.Narium (Beitrag 1505245)

Nur wenn dabei gleich rauskommt, könnten die Dateien auch inhaltlich gleich sein. Erst dann kann mit der MD5-Checksumme (oder eine andere Checksumme) festgestellt werden, ob die Dateien nun wirklich gleich sind oder nicht.

Es macht keinen Sinn eine Checksumme über die komplette Datei zu erstellen um diese dann zu vergleichen. Erstens kann es dabei Kollisionen geben und zweitens müssen dafür beide Dateien komplett gelesen werden. Die Wahrscheinlichkeit, dass es - insbesondere bei einem falsch vergebenen Dateinamen - schon am Anfang der Dateien Unterschiede gibt, ist aber relativ hoch.

Deshalb macht es hier tatsächlich Sinn die Dateien von vorne an durchzugehen und direkt zu vergleichen, wenn die Dateigröße übereinstimmt.

Da Zip-Dateien meines Wissens kein zentrales Inhaltsverzeichnis haben, sondern alle Informationen in den lokalen Headern der einzelnen Dateien stehen, muss auch dafür viel gelesen werden, aber gerade bei größeren Dateien im Archiv könnte man einiges überspringen, so dass es auf diese Weise dennoch schneller gehen kann als wenn man alles liest.

Bei allen mir bekannten ZIP-Dateien steht das Inhaltsverzeichnis am Ende der ZIP-Datei (https://en.wikipedia.org/wiki/ZIP_(f...ry_file_header).

Wenn man byteweise vergleicht und der Unterschied am Anfang zu finden ist, kann man viel Zeit sparen. Wenn er am Ende steht eher nicht. Ist also alles ein bisserl Glücksache. Bei einer statistischen Normalverteilung der Unterschiede könnte sich die Laufzeit hier allerdings durchaus halbieren ;-)

Kollisionen bei Checksummen sind immer möglich, aber im realen Leben sehr selten anzufinden.
Bei der MD5-Checksumme können sie vorkommen, sind mir im realen Leben allerdings noch nicht begegnet (und das bei etlichen Millionen von Datenvergleichen / nicht nur Dateien, Blobfelder in Datenbanken ..., nicht nur ab und an mal so ein paar).

Unklar ist bei der Aufgabenstellung allerdings: Wie oft kommen identische Dateigrößen überhaupt vor?
Mit der Folge: Wie oft ist ein Checksummenvergleich oder ein byteweiser Vergleich überhaupt erforderlich?

Mehrfach täglich oder einmal im Jahr?

Lohnt dann der Aufwand der Implementierung des byteweisen Vergleiches oder nehmen wir sporadisch mal die hohe Laufzeit für die Ermittlung der MD5-Checksummen in kauf?

[gee21]

Delphi-Quellcode:

Unklar ist bei der Aufgabenstellung allerdings: Wie oft kommen identische Dateigrößen überhaupt vor?
Mit der Folge: Wie oft ist ein Checksummenvergleich oder ein byteweiser Vergleich überhaupt erforderlich?

Die Dateien hätten nur den selben Namen und die Selbe Dateigrösse wenn jemand willentlich unsere Backups auf dem Hauptserver manipuliert.

(Er erstellt Fake backups / bennent sie um und ergänzt die fehlenden bytes mit "fake Daten".) Theoretisch sollte die Backupsoftware des Server dann nichts Synchronsieren (sofern die backup software des Servers auch mit Dateigrössen vergleich arbeitet, das weiss ich aber nicht genau)

oder

(Er erstellt Fake backups / bennent sie um und ergänzt die fehlenden bytes NICHT mit "fake Daten".) Da hätten wir dann das Problem das die Backup Software des Server diese Daten wohl überschreiben würde. (Synchronisierung).

[jobo]

ich würde sowas
1. lokal statt im Netz machen (alte und neue Datei lokal)
2. mit existierenden Tools, z.B. rsync (das es zufällig auch remote könnte)
folglich, nicht selbst programmieren.

[Delphi.Narium]

Zitat:

Zitat von gee21 (Beitrag 1505252)

Delphi-Quellcode:

Unklar ist bei der Aufgabenstellung allerdings: Wie oft kommen identische Dateigrößen überhaupt vor?
Mit der Folge: Wie oft ist ein Checksummenvergleich oder ein byteweiser Vergleich überhaupt erforderlich?

Die Dateien hätten nur den selben Namen und die Selbe Dateigrösse wenn jemand willentlich unsere Backups auf dem Hauptserver manipuliert.

(Er erstellt Fake backups / bennent sie um und ergänzt die fehlenden bytes mit "fake Daten".) Theoretisch sollte die Backupsoftware des Server dann nichts Synchronsieren (sofern die backup software des Servers auch mit Dateigrössen vergleich arbeitet, das weiss ich aber nicht genau)

oder

(Er erstellt Fake backups / bennent sie um und ergänzt die fehlenden bytes NICHT mit "fake Daten".) Da hätten wir dann das Problem das die Backup Software des Server diese Daten wohl überschreiben würde. (Synchronisierung).

Es geht also darum, eine Alarmanlage einzubauen, die im Normalfall und im Idealfall nie einen Alarm auslösen muss, da der Zustand, der von ihr überprüft wird, im Regelbetrieb nicht vorkommen kann / darf.

Zitat:

Zitat von jobo (Beitrag 1505254)

ich würde sowas
1. lokal statt im Netz machen (alte und neue Datei lokal)
2. mit existierenden Tools, z.B. rsync (das es zufällig auch remote könnte)
folglich, nicht selbst programmieren.

Aber auch die muss man nur "anwerfen", wenn obige "Alarmanlage" bei Dateigrößen bzw. Dateinamendubletten auslösen sollte.

[gee21]

Zitat:

Zitat von jobo (Beitrag 1505254)

ich würde sowas
1. lokal statt im Netz machen (alte und neue Datei lokal)
2. mit existierenden Tools, z.B. rsync (das es zufällig auch remote könnte)
folglich, nicht selbst programmieren.

Also die Backups kommen vom Internet her und werden auf dem NAS gespeichert. Dann wird es Lokal in einen Ordner kopiert (mein Tool soll das tun). und dieser Ordner wiederum wird dann an diverse Standorte und Festplatten synchronisiert.

Betreffend RSYNC:
Ja es ist eben alleine mit RSYNC / FTPSync nicht möglich aus meiner Sicht. (Kann auch sein das ich was falsch überlege)

Entweder Synchronisiert RSYNC. = problem bei fake backups synchronisiert er dann einfach auch mit.

oder wir können sagen: Zusätzliche Daten am Ziel aufbewahren. aber auch dass lösst das problem nicht (falls es andere Dateien mit dem selben namen sind). Zudem würde der Speicherplatz dann immer wieder voll werden.

Oder wir könnten jeden Tag in einen neuen Ordner ablegen. Dann würde aber auch der Speicherplatz problematisch.

und es gibt noch die option: Nur geänderte daten übetragen. aber auch dass lösst das problem nicht (falls es andere Dateien mit dem selben namen sind).

[gee21]

Zitat:

Es geht also darum, eine Alarmanlage einzubauen, die im Normalfall und im Idealfall nie einen Alarm auslösen muss, da der Zustand, der von ihr überprüft wird, im Regelbetrieb nicht vorkommen kann / darf.

Ja genau :thumb:

[himitsu]

NAS ...

Warum SMB?

via SSH, da kann die Berechnung des HASH auf der anderen Seite erfolgen, also für die Berechnung muß die Datei nicht erst übertragen werden, sondern nur noch der kleine HASH.


rsync sollte das darüber auch schneller/sparsamer sein

[gee21]

Zitat:

Zitat von himitsu (Beitrag 1505262)

NAS ...

Warum SMB?

via SSH, da kann die Berechnung des HASH auf der anderen Seite erfolgen, also für die Berechnung muß die Datei nicht erst übertragen werden, sondern nur noch der kleine HASH.


rsync sollte das darüber auch schneller/sparsamer sein

Ohh ich wusste nicht das man über SSH den HASH direkt so auslesen kann... Danke :thumb:
Ich nutze SMB weil es einfach geht in kombination mit Delphi und es sowieso bereits auf allen Windows Rechnern eingerichtet (zB Netzlaufwerk T: oder S: etc).

Damit ich in Windows eine SSH Verbindung mache konnte habe ich bis jetzt immer Putty verwendet. Ich nehme mal an ich müsste also in Delphi eine SSH verbindung aufbauen anstatt auf die Netzlaufwerke zuzugreifen. Man kann nicht ein Netzlaufwerk einrichten das dann über SSH läuft anstelle von SMB, oder doch?

Hab gesehen es gibt folgende Komponente, Würde es theoretisch mit dieser gehen?

https://torry.net/pages.php?id=1578
TGPuttyLib v.1

(ich denke aber es ist eh zu hoch für mich).

[himitsu]

Einfach auslesen nicht direkt (OK, einige Dateisysteme speichern optional auch direkt einen Hash, den man lesen könnte, z.B. Btrfs),
aber da wird das Hash-Berechnunsprogramm ja einfach auf dem anderen Rechner (NAS) ausgeführt, ohne die Datei erst runterladen zu müssen, und dessen Ausgabe (der Hash), kommt dann ganz schnell über Leitung zurück.


Ich weiß jetzt nicht ob wirklich rsync oder eines der anderen Programmchen, aber ich glaube rsync konnte die Dateien Blockweise hashen und nur den Hash bergleichen, anstatt jedes Byte einzeln, womit es dann schneller geht, wenn jeweils die Hashs auf den Seiten berechnet werden, auf welchen die Dateien liegen.


SSH ist ja erstmal nur die Console/Terminal ... Dateilisten und -übertragung machen dann Programme.
z.B. FTPS vs. SFTP ... das Eine ist FTP durch seinen SSL/TSL Tunnel, das Andere sieht wie FTP aus, aber es öffnet intern quasi ein Terminal, wo es dann entsprechende Befehle ausfürt.


Es selber machen (hashs berechnen lassen, vergleichen und dann die Datei übertragen oder nicht) ist wohl nicht nötig.
SCP oder RSYNC kannst du ja einfach aus Delphi heraus aufrufen.

[jobo]

Zitat:

Zitat von gee21 (Beitrag 1505256)

Betreffend RSYNC:
Ja es ist eben alleine mit RSYNC / FTPSync nicht möglich aus meiner Sicht. (Kann auch sein das ich was falsch überlege)

Entweder Synchronisiert RSYNC. = problem bei fake backups synchronisiert er dann einfach auch mit.

rsync hat eine checksum Option. File Date wird in dem Falle ignoriert, außerdem hat es einen Dry Run Schalter.

[gee21]

OK alles klar.

Ich bedanke mich rechtherzlich bei allen :thumb:
Hab wieder mal viel gelernt und denke dass ich mit all diesen Informationen eine Lösung finde.

[Redeemer]

Warum vergleicht man nicht das CRC32, das bereits in den ZIP-Dateien steht, zusammen mit der Dateigröße? Das sollte hinreichend genau sein.

[dummzeuch]

Zitat:

Zitat von himitsu (Beitrag 1505264)

Ich weiß jetzt nicht ob wirklich rsync oder eines der anderen Programmchen, aber ich glaube rsync konnte die Dateien Blockweise hashen und nur den Hash bergleichen, anstatt jedes Byte einzeln, womit es dann schneller geht, wenn jeweils die Hashs auf den Seiten berechnet werden, auf welchen die Dateien liegen.

Standardmäßig verwendet rsync zum Vergleich den Timestamp der Dateien, um festzustellen, ob sie kopiert werden muss. Erst beim Kopieren versucht es blockweise zu kopieren und Prüfsummen zu übertragen, um Bandbreite zu sparen. Es gibt aber eine Option (--checksum wenn ich mich recht erinnere), bei der der initiale Vergleich anhand einer Prüsumme geschieht. Das ist dann allerdings um Größenordnungen langsamer.

rsync selbst kann der Fragesteller allerdings gar nicht einsetzen, außer um eine Datei ggf. lokal zu kopieren, was vielleicht schneller ist als der Zugriff via SMB.

Es ist jedoch wirklich ein gutes Beispiel, wie man es machen könnte, vorausgesetzt, man kann auf dem Server (NAS) Programme via ssh ausführen.

[dummzeuch]

Zitat:

Zitat von Redeemer (Beitrag 1505268)

Warum vergleicht man nicht das CRC32, das bereits in den ZIP-Dateien steht, zusammen mit der Dateigröße? Das sollte hinreichend genau sein.

Das setzt voraus, dass die Prüfsumme in der Datei nicht manipuliert ist. Aber manipulierte Dateinen scheinen ja eines der möglichen Probleme zu sein.

[jobo]

Zitat:

Zitat von dummzeuch (Beitrag 1505272)

rsync selbst kann der Fragesteller allerdings gar nicht einsetzen, außer um eine Datei ggf. lokal zu kopieren, was vielleicht schneller ist als der Zugriff via SMB.

Es ist jedoch wirklich ein gutes Beispiel, wie man es machen könnte, vorausgesetzt, man kann auf dem Server (NAS) Programme via ssh ausführen.

Warum kann man (hier) kein rsync einsetzen?

Es ist m.E. nicht nur ein gutes Beispiel, es ist auch fraglich, ob unter der ausgegebenen Herangehensweise etwas schnell, sicher und einfach neu entsteht, was es seit Jahrzehnten bewährt gibt.

Ein NAS, das kein SSH kann, wäre natürlich hinderlich, aber nicht nur für rsync. Ideal würde ein solches Programm natürlich dort laufen, wo die Dateien landen. Aber dort sind sie ja nicht festgetackert.