Forum: PC-Programmierung FTP und Dateiprüfsumme (CRC)


von Gerald K. (geku)


Lesenswert?

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
von Hmmm (Gast)


Lesenswert?

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?

von Max M. (jens2001)


Lesenswert?

Gerald K. schrieb:
> Auch der CRC müsste sich
> geändert haben.

Von welchem CRC faselst du!

von imonbln (Gast)


Lesenswert?

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.

von Gerald K. (geku)


Lesenswert?

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.

von Gerald K. (geku)


Lesenswert?

Max M. schrieb:
> Von welchem CRC faselst du!

Dateiprüfsumme

von Nop (Gast)


Lesenswert?

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.

von Gerald K. (geku)


Lesenswert?

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
von 2⁵ (Gast)


Lesenswert?

Gerald K. schrieb:
> Oder ist der CRC nicht über FTP zugreifbar?

Genau das ist das Problem!

von (prx) A. K. (prx)


Lesenswert?

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.

von Nop (Gast)


Lesenswert?

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.

von Gerald K. (geku)


Lesenswert?

A. K. schrieb:
> Konvertierung zwischen verschiedenen Textfile-Formaten durchgeführt wird
> - ascii/binary mode.

Wie äußert sich diese Konvertierung?

von Irgend W. (Firma: egal) (irgendwer)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Gerald K. (geku)


Lesenswert?

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

von Gerald K. (geku)


Lesenswert?

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
von Christoph db1uq K. (christoph_kessler)


Lesenswert?

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

von Local Area Notwork (Gast)


Lesenswert?

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.

von Max M. (jens2001)


Lesenswert?

Gerald K. schrieb:
> Max M. schrieb:
>> Von welchem CRC faselst du!
>
> Dateiprüfsumme

Und wo soll die sein?

von PittyJ (Gast)


Lesenswert?

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.

von Miethai (Gast)


Lesenswert?

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.

von Jemand (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.