Wenn die Gleichheit zweier Dateien über FTP festgestellt werden soll, wie kann am effizientesten vorgegangen werden. Vergleich : Änderungsdatum, Dateigröße, Inhalt (Byte für Byte Vergleich), Prüfsumme. In welcher Reihenfolge sollten diese Parameter verglichen werden. Der Byte für Byte Vergleich ist am aufwendigsten, da alle Daten auch im Verdachtsfall über TFP übertragen werden müssen. Hintergrund : ich verwende ein Programm zur Synchronisierung zweier PCs übers Internet. Dabei habe ich festgestellt, wenn ich in einer Datei nur einen Buchstaben ändere, dann wird nicht synchronisiert. Füge ich einen Buchstaben dazu und die Datei wird damit größer, dann funktioniert auch die Synchronisation. Ich denke das ist ein Fehler. Anscheinend wird nur die Größe der Datei überprüft. Es muss sich doch auch der Zeitstempel der Datei geändert haben. Auch der CRC müsste sich geändert haben. Oder ist der CRC nicht über TFP zugreifbar? Habt ihr ähnliche Erfabrungen?
:
Bearbeitet durch User
Gerald K. schrieb: > Anscheinend wird nur die Größe der Datei überprüft. Es muss sich doch > auch der Zeitstempel der Datei geändert haben. Normalerweise schon, das kannst Du ja manuell prüfen. Gerald K. schrieb: > Oder ist der CRC nicht über TFP zugreifbar? Standardmässig gibt es im Protokoll nichts in der Richtung. Aber muss es unbedingt FTP sein?
Gerald K. schrieb: > Hintergrund : ich verwende ein Programm zur Synchronisierung zweier > PCs übers Internet Unter Linux/Unix hat sich hierfür das Rsync Protokoll durchgesetzt. Bist Du durch widersinnige Corporate vorgaben auf, dass alte Drecks FTP Protokoll festgelegt oder hast Du die Chance was Besseres für Deine Aufgabe zu nutzen? Denn wie Du merkst hat FTP mit der Zeit mehr als ein Problem bekommen, aber das Protokoll ist ja auch von 1971 Computer technisch also kurz vor der Steinzeit, von daher wird es Zeit diesen Dinosaurier in würde sterben zu lassen, seine Zeit ist schon lange abgelaufen.
Hmmm schrieb: > Normalerweise schon, das kannst Du ja manuell prüfen. Ja, habe ich, aber ich werde es nochmals kontrollieren. Vor allem werde ich es noch mit einer anderen Applikation querchecken. Hmmm schrieb: > Standardmässig gibt es im Protokoll nichts in der Richtung. Aber muss es > unbedingt FTP sein? Ja, leider unterstützt die Applikation nur FTP für den Fernzugriff.
Auf Zeitstempel sollte man sich nicht verlassen, die sind notorisch unzuverlässig. Ich würde es so machen: Dateigröße verschieden? Änderung. Prüfsumme verschieden? Änderung. So, und jetzt kommt's drauf an, was Du als Prüfsumme genommen hast. Bei CRC-32 mußt Du jetzt byteweise vergleichen, weil bei nur 32 Bit die Wahrscheinlichkeit einer Prüfsummenkollision zu hoch wird. Bei 65536 Dateien hast Du eine 50%-Chance auf eine Kollision (Geburtstagsparadoxon). Nimmst Du hingegen sha256, kannst Du davon ausgehen, daß es keine Kollisionen geben wird und kannst Dir den Bytevergleich sparen.
Nop schrieb: > Nimmst Du hingegen sha256, kannst Du davon ausgehen, daß es keine > Kollisionen geben wird und kannst Dir den Bytevergleich sparen. Nur muß ich vor der Berechnung des sha256 die Datei vom Quellsystem übers Internet auf Zielsystem kopieren. Das ist sehr zeitraubend und bringt viel Datenvolumen, da spielt der Vergleich am Zielsystem keine Rolle mehr.
:
Bearbeitet durch User
Bei FTP sollte man ein wenig aufpassen, da in manchen Konstellationen ohne weitere Massnahmen eine Konvertierung zwischen verschiedenen Textfile-Formaten durchgeführt wird - ascii/binary mode.
Gerald K. schrieb: > Nur muß ich vor der Berechnung des sha256 die Datei vom Quellsystem > übers Internet auf Zielsystem kopieren. Äh, nein. Du kopierst nur eine Liste Deines Verzeichnisses mit den zugehörigen Hashes. Die Liste gleicht der Server dann mit dem ab, was er hat.
A. K. schrieb: > Konvertierung zwischen verschiedenen Textfile-Formaten durchgeführt wird > - ascii/binary mode. Wie äußert sich diese Konvertierung?
Nop schrieb: > Du kopierst nur eine Liste Deines Verzeichnisses mit den > zugehörigen Hashes. Die Liste gleicht der Server dann mit dem ab, was er > hat. Prizipiell der richtige Weg. Aber es setzt vorraus das bei hochladen der Dateien eine entsprechende Liste angelegt/gepflegt wird. FTP macht da von sich aus garnichts.
Gerald K. schrieb: > A. K. schrieb: >> Konvertierung zwischen verschiedenen Textfile-Formaten durchgeführt wird >> - ascii/binary mode. > > Wie äußert sich diese Konvertierung? Dürfte von Plattform und Programm abhängig sein. Kann man abschalten. Google "ascii/binary mode" führt direkt zu https://www.jscape.com/blog/ftp-binary-and-ascii-transfer-types-and-the-case-of-corrupt-files
:
Bearbeitet durch User
A. K. schrieb: > Dürfte von Plattform und Programm abhängig sein. Kann man abschalten. Es gibt (oder gab) bei Textdateien ein Zeichen für das Ende des Textes ^Z https://en.m.wikipedia.org/wiki/End-of-file
Irgend W. schrieb: > FTP macht da von sich aus garnichts. Genau das wollte ich bestätigt haben. Ein Applikation zur Sychronisierung, die nur im eigenen System arbeitet kann nur auf Zeitstempel und Länge zurück greifen, bevor durch Übertragung der Daten ein Vergleich durchgeführt werden muss. Wobei Zeitstempel und Länge keine 100% Gewissheit bieten. So gesehen ist immer ein Byte für Byte notwendig, oder?
:
Bearbeitet durch User
Ähnlich unerwartet: Ein Skript aus einem Linuxrechner (embedded PC) mit Filezilla in den Windowsrechner geladen und mangels besseren Editors in Wordpad betrachtet. Das fügt ungefragt vor jedem 0A noch ein 0D ein. Nach anschließendem Rückschreiben funktioniert das Skript nicht mehr.
Geht es nun um FTP oder TFTP? TFP ist mir nicht geläufig... Lösungsansätz: Prüfsummen der Dateien auf beiden Systemen (local & remote) vorhalten. Wenn eines der 2 Systeme "schwach" in Rechenleistung ist, muss man halt Kompromisse eingehen: auf einem <0.5GHz getakteten 32bitter wird SHA eine Frage der Geduld... Auch rsync verlangt seinen Anteil an Rechenleistung, da kann nicht jedes Embedded-System einfach so mitziehen. Damals[TM] musste ich aus gegebenen Umständen auch was rund um FTP scripten um Archive der Buildartefakte (letztlich ISO-images) auf dem vom Brötchengeber vorgegebenen Uralt-Archivserver mit limitiertem Toolset korrekt zu spiegeln.
Gerald K. schrieb: > Max M. schrieb: >> Von welchem CRC faselst du! > > Dateiprüfsumme Und wo soll die sein?
Ich nehme immer MD5. https://de.wikipedia.org/wiki/Message-Digest_Algorithm_5 Ist vielleicht kryptographisch nicht mehr ganz auf der Höhe der Zeit. Aber für diese Anwendung ist er vollkommen ausreichend. z.B. unter Linux ganz einfach mit: $ md5sum mozilla.pdf 5bd9143628ec975802f34939c60cf0e7 mozilla.pdf Das kann man in Skripts wunderbar weiter verwenden.
Gerald K. schrieb: > Hintergrund : ich verwende ein Programm zur Synchronisierung zweier > PCs übers Internet. Dabei habe ich festgestellt, wenn ich in einer Datei "Ein Programm" was ist das genau? Das spricht ftp? Für synchronisation nimmt man rsync.
PittyJ schrieb: > Ich nehme immer MD5. > https://de.wikipedia.org/wiki/Message-Digest_Algorithm_5 > Ist vielleicht kryptographisch nicht mehr ganz auf der Höhe der Zeit. > Aber für diese Anwendung ist er vollkommen ausreichend. > > z.B. unter Linux ganz einfach mit: > $ md5sum mozilla.pdf > 5bd9143628ec975802f34939c60cf0e7 mozilla.pdf > > Das kann man in Skripts wunderbar weiter verwenden. Es spricht hier zwar nichts gegen MD5, aber dennoch: BLAKE2b (b2sum) ist kryptographisch auf Höhe der Zeit und sogar schneller, zumindest auf 64 Bit-Systemen.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.