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