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


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Gerald K. (geku)


Bewertung
0 lesenswert
nicht 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)


Bewertung
1 lesenswert
nicht 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)


Bewertung
-1 lesenswert
nicht lesenswert
Gerald K. schrieb:
> Auch der CRC müsste sich
> geändert haben.

Von welchem CRC faselst du!

von imonbln (Gast)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> Von welchem CRC faselst du!

Dateiprüfsumme

von Nop (Gast)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


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

Genau das ist das Problem!

von A. K. (prx)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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 A. K. (prx)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


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

Und wo soll die sein?

von PittyJ (Gast)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.