Grosse Dateien vergleichen. Schnell, Sicher und Einfach ;)

[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

[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 von 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

Ohh ich wusste nicht das man über SSH den HASH direkt so auslesen kann... Danke
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 von gee21:

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
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 von himitsu:

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 von Redeemer:

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 von dummzeuch:

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.