Wie wissen Programme, die fehlgeschlagene Dateiübertragungen fortsetzen können, wo sie Daten anhängen sollen?

Einige Programme zum Kopieren von Dateien mögen rsyncund curlkönnen fehlgeschlagene Übertragungen / Kopien fortsetzen.

Beachten Sie, dass es viele Ursachen für diese Fehler geben kann. In einigen Fällen kann das Programm "aufräumen", in einigen Fällen kann das Programm nicht.

Wenn diese Programme fortgesetzt werden, scheinen sie nur die Größe der Datei / Daten zu berechnen, die erfolgreich übertragen wurden, und beginnen einfach, das nächste Byte von der Quelle zu lesen und an das Dateifragment anzuhängen.

ZB beträgt die Größe des Dateifragments, das es zum Ziel "geschafft" hat, 1378 Bytes. Sie lesen also erst ab Byte 1379 des Originals und fügen es dem Fragment hinzu.

Meine Frage ist, zu wissen, dass Bytes aus Bits bestehen und nicht alle Dateien ihre Daten in sauberen, bytegrossen Blöcken segmentieren. Woher wissen diese Programme, dass der Punkt, an dem sie mit dem Hinzufügen von Daten begonnen haben, korrekt ist?

Beim Schreiben der Zieldatei kommt es zu einer Art Pufferung oder zu "Transaktionen" ähnlich wie bei SQL-Datenbanken, entweder auf Programm-, Kernel- oder Dateisystemebene, um sicherzustellen, dass nur saubere, wohlgeformte Bytes zum zugrunde liegenden Blockgerät gelangen?
Oder gehen die Programme davon aus, dass das letzte Byte möglicherweise unvollständig ist, und löschen es unter der Annahme, dass es fehlerhaft ist, kopieren Sie das Byte erneut und starten Sie das Anhängen von dort aus?

Da nicht alle Daten als Bytes dargestellt werden, scheinen diese Vermutungen falsch zu sein.

Wenn diese Programme "wieder aufgenommen" werden, woher wissen sie, dass sie an der richtigen Stelle starten?

Der Übersichtlichkeit halber - die eigentliche Mechanik ist komplizierter, um noch mehr Sicherheit zu gewährleisten - können Sie sich den Vorgang zum Schreiben auf die Festplatte folgendermaßen vorstellen:

• Anwendung schreibt Bytes (1)
• Der Kernel (und / oder das Dateisystem IOSS) puffert sie
• wenn der Puffer voll ist, wird es gespült , um das Dateisystem:
  • der Block ist belegt (2)
  • der Block ist geschrieben (3)
  • die Datei- und Blockinformationen werden aktualisiert (4)

Wenn der Vorgang bei (1) unterbrochen wird, befindet sich nichts auf der Festplatte, die Datei ist intakt und wurde im vorherigen Block abgeschnitten. Sie haben 5000 Bytes gesendet, nur 4096 befinden sich auf dem Datenträger. Sie starten die Übertragung bei Offset 4096 neu.

Wenn bei (2), passiert nichts außer im Speicher. Gleich wie (1). Wenn bei (3), werden die Daten geschrieben, aber niemand merkt sich darüber . Sie haben 9000 Bytes gesendet, 4096 wurden geschrieben, 4096 wurden geschrieben und gingen verloren , der Rest ging gerade verloren. Die Übertragung wird bei Offset 4096 fortgesetzt.

Wenn bei (4), sollten die Daten jetzt auf der Festplatte festgeschrieben worden sein. Die nächsten Bytes im Stream gehen möglicherweise verloren. Sie haben 9000 Bytes gesendet, 8192 wurden geschrieben, der Rest geht verloren, die Übertragung wird mit Versatz 8192 fortgesetzt.

Dies ist eine vereinfachte Einstellung. Beispielsweise ist jeder "logische" Schreibvorgang in den Stufen 3-4 nicht "atomar", sondern führt zu einer anderen Sequenz (Nummer 5), wobei der Block in Unterblöcke unterteilt wird, die für das Zielgerät geeignet sind (z. B. Festplatte) ) wird an den Host-Controller des Geräts gesendet, der ebenfalls über einen Caching-Mechanismus verfügt , und schließlich auf der Magnetplatte gespeichert. Diese Teilsequenz unterliegt nicht immer vollständig der Kontrolle des Systems, sodass das Senden von Daten auf die Festplatte keine Garantie dafür ist, dass sie tatsächlich geschrieben wurden und wieder lesbar sind.

Mehrere Dateisysteme implementieren die Journalerstellung , um sicherzustellen, dass der verwundbarste Punkt (4) nicht tatsächlich verwundbar ist, indem sie, wie Sie vermutet haben, Metadaten in Transaktionen schreiben, die in jedem Fall konsistent funktionieren (5).

Wenn das System während einer Transaktion zurückgesetzt wird, kann es seinen Weg zum nächsten intakten Prüfpunkt fortsetzen. Die geschriebenen Daten gehen immer noch verloren, genau wie in Fall (1), die Wiederaufnahme wird sich jedoch darum kümmern. Es gehen keine Informationen verloren.

Hinweis: Ich habe weder die Quellen rsyncnoch ein anderes Dienstprogramm für die Dateiübertragung untersucht.

Es ist trivial, ein C-Programm zu schreiben, das das Ende einer Datei überspringt und die Position dieser Position in Bytes abruft.

Beide Operationen werden mit einem einzigen Aufruf der Standard-C-Bibliotheksfunktion ausgeführt lseek()( lseek(fd, 0, SEEK_END)gibt die Länge der für den Dateideskriptor geöffneten Datei fdin Byte zurück).

Sobald das für die Zieldatei durchgeführt wird, zu einem ähnlichen Anruf lseek()kann auf der Quelldatei durchgeführt werden , um die entsprechenden Stelle zu springen: lseek(fd, pos, SEEK_SET). Die Übertragung kann dann an diesem Punkt fortgesetzt werden, vorausgesetzt, der frühere Teil der Quelldatei wurde als unverändert identifiziert (verschiedene Dienstprogramme können dies auf unterschiedliche Weise tun).

Eine Datei kann auf der Festplatte fragmentiert sein , das Dateisystem stellt jedoch sicher, dass eine Anwendung die Datei als eine sequentielle Folge von Bytes erkennt.

Zur Diskussion in Kommentaren zu Bits und Bytes: Die kleinste Dateneinheit, die auf die Festplatte geschrieben werden kann, ist ein Byte . Für ein einzelnes Byte muss mindestens ein Datenblock auf der Festplatte zugewiesen werden. Die Größe eines Blocks hängt von der Art des Dateisystems und möglicherweise auch von den Parametern ab, die der Administrator beim Initialisieren des Dateisystems verwendet, liegt jedoch normalerweise zwischen 512 Byte und 4 KB. Schreibvorgänge können vom Kernel, der zugrunde liegenden C-Bibliothek oder von der Anwendung selbst gepuffert werden, und das eigentliche Schreiben auf die Festplatte kann als Optimierung in Vielfachen der entsprechenden Blockgröße erfolgen.

Es ist nicht möglich, einzelne Bits in eine Datei zu schreiben. Wenn ein Schreibvorgang fehlschlägt, verbleiben keine "halbgeschriebenen Bytes" in der Datei.

Dies sind im Grunde genommen zwei Fragen, da Programme wie curl und rsync sehr unterschiedlich sind.

Für HTTP-Clients wie curl überprüfen sie die Größe der aktuellen Datei und senden dann einen Content-RangeHeader mit ihrer Anfrage. Der Server setzt entweder das Senden des Bereichs der Datei unter Verwendung des Statuscodes 206(Teilinhalt) anstelle von 200(Erfolg) fort und der Download wird fortgesetzt, oder er ignoriert den Header und beginnt von vorne, und der HTTP-Client hat keine andere Wahl, als alles erneut herunterzuladen nochmal.

Ferner kann der Server einen Content-LengthHeader senden oder nicht . Möglicherweise haben Sie bemerkt, dass einige Downloads keinen Prozentsatz und keine Dateigröße aufweisen. Dies sind Downloads, bei denen der Server dem Client die Länge nicht mitteilt, sodass der Client nur die heruntergeladene Menge kennt, aber nicht, wie viele Bytes folgen werden.

Die Verwendung eines Content-RangeHeaders mit Start- und Stoppposition wird von einigen Download-Managern verwendet, um eine Datei aus verschiedenen Quellen gleichzeitig herunterzuladen. Dies beschleunigt die Übertragung, wenn jeder Spiegel für sich genommen langsamer ist als Ihre Netzwerkverbindung.

rsync hingegen ist ein erweitertes Protokoll für inkrementelle Dateiübertragungen. Es generiert Prüfsummen von Teilen der Datei auf Server- und Clientseite, um festzustellen, welche Bytes gleich sind. Dann werden nur die Differenzen gesendet. Dies bedeutet, dass nicht nur ein Download fortgesetzt, sondern auch die geänderten Bytes heruntergeladen werden können, wenn Sie einige Bytes in der Mitte einer sehr großen Datei geändert haben, ohne die Datei erneut herunterzuladen.

Ein anderes Protokoll zur Wiederaufnahme von Übertragungen ist bittorrent, wobei die .torrentDatei eine Liste von Prüfsummen für Blöcke aus der Datei enthält, sodass Blöcke in beliebiger Reihenfolge und parallel aus verschiedenen Quellen heruntergeladen und überprüft werden können.

Beachten Sie, dass rsync und bittorent die Teildaten auf Ihrer Festplatte überprüfen, während ein HTTP-Download nicht fortgesetzt wird. Wenn Sie also den Verdacht haben, dass die Teildaten beschädigt sind, müssen Sie die Integrität anderweitig überprüfen, dh mithilfe einer Prüfsumme der endgültigen Datei. Durch Unterbrechen des Downloads oder Unterbrechen der Netzwerkverbindung wird die Teildatei in der Regel nicht beschädigt, während ein Stromausfall während der Übertragung die Ursache sein kann.

TL; DR: Sie können nicht, es sei denn, das Protokoll, das sie verwenden, erlaubt es.

Programme können nicht immer von einem beliebigen Speicherort aus fortgesetzt werden. Beispielsweise können HTTP-Anforderungen nur neu gestartet werden, wenn der Server dies unterstützt und der Client dies implementiert. Dies ist nicht universell. Überprüfen Sie daher die Dokumentation Ihres Programms. Wenn der Server dies unterstützt, können Programme die Übertragung fortsetzen, indem sie einfach als Teil des Protokolls nachfragen. In Ihrem Download-Verzeichnis werden in der Regel teilweise Übertragungen angezeigt (häufig sind sie mit einer ".partial" -Erweiterung oder ähnlichem gekennzeichnet).

Wenn ein Dateidownload angehalten oder auf andere Weise angehalten wird, kann der Client die Datei auf die Festplatte schreiben und eine genaue Vorstellung davon haben, wo sie fortgesetzt werden soll. Wenn der Client andererseits abstürzt oder ein Fehler beim Schreiben in die Datei auftritt, muss der Client davon ausgehen, dass die Datei beschädigt ist, und neu beginnen. BitTorrent mildert dies ein wenig, indem es die Dateien in "Chunks" aufteilt und nachverfolgt, welche erfolgreich heruntergeladen wurden. das meiste, was es jemals wiederholen muss, sind ein paar Brocken. Rsync macht etwas Ähnliches.

Woher wissen Programme, dass der Inhalt derselbe ist? Eine Methode besteht darin, zu überprüfen, ob eine Kennung zwischen Client und Server identisch ist. Einige Beispiele hierfür sind der Zeitstempel und die Größe, aber es gibt Mechanismen , die für ein Protokoll spezifisch sein können. Stimmen die Bezeichner überein, kann der Client davon ausgehen, dass die Wiederaufnahme funktioniert.

Wenn Sie eine genauere Bestätigung wünschen, sollten HTTP und Freunde nicht Ihre erste Wahl sein. Sie sollten ein Protokoll verwenden, das auch eine Prüfsumme oder einen Hash für die gesamte Datei und jeden übertragenen Block enthält, damit Sie die Prüfsumme des Downloads mit der Prüfsumme des Servers vergleichen können. Alle nicht übereinstimmenden Daten werden dann erneut heruntergeladen. Auch hier ist BitTorrent ein Beispiel für diese Art von Protokoll. Optional kann das auch rsync.

Hängt vom verwendeten Übertragungsprotokoll ab. Aber curl verwendet http und überträgt die Daten sequenziell in der Reihenfolge, in der sie in der Datei erscheinen. Das Einrollen kann also basierend auf der Dateigröße einer teilweise abgeschlossenen Übertragung fortgesetzt werden. Tatsächlich können Sie es täuschen, um die ersten N Bytes zu überspringen, indem Sie eine Datei mit der Länge N (von irgendetwas) erstellen und sie bitten, diese Datei als teilweise abgeschlossenen Download zu behandeln (und dann die ersten N Bytes zu verwerfen).