失敗したファイル転送を再開できるプログラムは、データの追加を開始する場所をどのように知っていますか？

以下のようないくつかのファイルコピープログラムrsyncとは、curl失敗した転送/コピーを再開する能力を持っています。

これらの失敗の多くの原因が存在する可能性があることに注意してください。場合によっては、プログラムができない「クリーンアップ」を行うことができます。

これらのプログラムが再開すると、正常に転送されたファイル/データのサイズを計算し、ソースから次のバイトの読み取りを開始し、ファイルフラグメントに追加するだけのようです。

たとえば、宛先に「作成」されたファイルフラグメントのサイズは1378バイトなので、元のバイト1379から読み取りを開始し、フラグメントに追加します。

私の質問は、バイトがビットで構成されており、すべてのファイルのデータがきれいなバイトサイズのチャンクにセグメント化されているわけではないことを知っています。これらのプログラムは、データの追加を開始することを選択したポイントが正しいことをどのように知るのですか？

宛先ファイルの書き込み時に、プログラム、カーネル、またはファイルシステムレベルで発生するSQLデータベースに似た何らかのバッファリングまたは「トランザクション」が行われ、クリーンで整形式のバイトのみが基礎となるブロックデバイスに送られるようにしますか？
または、プログラムは最新のバイトが不完全である可能性があると想定しているので、不良であると想定して削除し、バイトを再コピーしてそこから追加を開始しますか？

すべてのデータがバイトとして表されるわけではないことを知っているため、これらの推測は間違っているように見えます。

これらのプログラムが「再開」するとき、適切な場所から開始していることをどのようにして知るのでしょうか？

わかりやすくするために、実際の仕組みはさらに複雑で、セキュリティがさらに向上しています。ディスクへの書き込み操作は次のように想像できます。

• アプリケーションがバイトを書き込む（1）
• カーネル（および/またはファイルシステムIOSS）はそれらをバッファリングします
• バッファがいっぱいになると、ファイルシステムにフラッシュされます。
  • ブロックが割り当てられます（2）
  • ブロックが書き込まれます（3）
  • ファイルとブロックの情報が更新されます（4）

プロセスが（1）で中断された場合、ディスク上には何も表示されず、ファイルはそのままで前のブロックで切り捨てられます。5000バイトを送信しましたが、ディスク上には4096しかありません。オフセット4096で転送を再開します。

（2）の場合、メモリ以外では何も起こりません。（1）と同じ。（3）の場合、データは書き込まれますが、それについて誰も覚えていません。9000バイトを送信し、4096が書き込まれ、4096が書き込まれて失われ、残りは失われました。転送はオフセット4096から再開します。

（4）の場合、データはディスクにコミットされているはずです。ストリームの次のバイトが失われる可能性があります。9000バイトを送信し、8192が書き込まれ、残りは失われ、オフセット8192で転送が再開されます。

これは簡略化されたテイクです。たとえば、ステージ3〜4の各「論理」書き込みは「アトミック」ではありませんが、別のシーケンス（＃5に番号を付けます）を生成します。 ）は、キャッシングメカニズムも備えたデバイスのホストコントローラーに送信され、最終的に磁気プラッターに保存されます。このサブシーケンスは、常に完全にシステムの制御下にあるとは限らないため、ハードディスクにデータを送信したからといって、実際に書き込まれ、読み戻せるという保証はありません。

複数のファイルシステムが実装ジャーナリング、最も脆弱なポイント、（4）が、ではないことを確認するために、実際にメタデータを書き込むことにより、脆弱な、あなたはそれを推測し、取引の段階（5）で起こるものは何でも一貫して動作します。

トランザクションの途中でシステムがリセットされた場合、最も近い無傷のチェックポイントに戻ることができます。書き込まれたデータは、ケース（1）と同じように失われますが、再開が処理します。実際に情報が失われることはありません。

注：私は、ソースrsyncや他のファイル転送ユーティリティを見ていません。

ファイルの末尾にジャンプしてその場所の位置をバイト単位で取得するCプログラムを記述するのは簡単です。

両方の操作は、標準のCライブラリ関数への単一の呼び出しで行われlseek()（lseek(fd, 0, SEEK_END)ファイル記述子のための開かれたファイルの長さを返しfdバイトで測定し、）。

これがターゲットファイルに対してlseek()実行されると、ソースファイルに対して同様の呼び出しが実行され、適切な位置にジャンプしますlseek(fd, pos, SEEK_SET)。その後、ソースファイルの以前の部分が変更されていないと識別されたと仮定して、転送はその時点で続行されます（異なるユーティリティは異なる方法でこれを行うことがあります）。

ファイルはディスク上で断片化される場合がありますが、ファイルシステムは、アプリケーションがファイルをバイトのシーケンシャルシーケンスとして認識することを保証します。

ビットとバイトに関するコメントでの議論について：ディスクに書き込まれるデータの最小単位はバイトです。1バイトでは、少なくとも1 ブロックのデータをディスクに割り当てる必要があります。ブロックのサイズは、ファイルシステムのタイプと、場合によってはファイルシステムの初期化時に管理者が使用するパラメーターにも依存しますが、通常は512バイトから4 KiBの間です。書き込み操作は、カーネル、基盤となるCライブラリ、またはアプリケーション自体によってバッファされ、実際のディスクへの書き込みは、最適化として適切なブロックサイズの倍数で行われる場合があります。

ファイルに単一ビットを書き込むことはできません。書き込み操作が失敗した場合、ファイルに「半分書き込まれたバイト」が残ることはありません。

curlとrsyncのようなプログラムは非常に異なるため、これは基本的に2つの質問です。

curlのようなHTTPクライアントの場合、現在のファイルのサイズを確認Content-Rangeし、リクエストとともにヘッダーを送信します。サーバー206は、200（成功）の代わりにステータスコード（部分コンテンツ）を使用してファイルの範囲の送信を再開し、ダウンロードを再開するか、ヘッダーを無視して最初から開始し、HTTPクライアントはすべてを再ダウンロードする以外の選択肢はありません再び。

さらに、サーバーはContent-Lengthヘッダーを送信する場合と送信しない場合があります。一部のダウンロードでは、割合とファイルサイズが表示されないことに気づいたかもしれません。これらは、サーバーがクライアントに長さを通知しないダウンロードであるため、クライアントはダウンロードした量のみを知っていますが、後に続くバイト数は知りません。

いくつかのダウンロードマネージャーはContent-Range、開始位置と停止位置でヘッダーを使用して、さまざまなソースからファイルを一度にダウンロードします。これにより、各ミラー自体がネットワーク接続よりも遅い場合、転送が高速化されます。

一方、rsyncは、増分ファイル転送用の高度なプロトコルです。サーバー側とクライアント側でファイルの一部のチェックサムを生成し、どのバイトが同じかを検出します。次に、差分のみを送信します。つまり、ダウンロードを再開することはできませんが、ファイルを再ダウンロードせずに非常に大きなファイルの途中で数バイトを変更した場合、変更されたバイトをダウンロードすることさえできます。

転送を再開するために作成された別のプロトコルはビットトレント.torrentです。ファイルには、ファイルからのブロックのチェックサムのリストが含まれているため、ブロックをダウンロードして、任意の順序で異なるソースから並行して検証できます。

rsyncとbittorentはディスク上の部分的なデータを検証しますが、HTTPダウンロードの再開は検証しません。そのため、部分データが破損している疑いがある場合は、整合性を確認する必要があります。つまり、最終ファイルのチェックサムを使用します。ただし、ダウンロードを中断したり、ネットワーク接続を失ったりしても、通常、部分的なファイルは破損しませんが、転送中の電源障害は発生します。

TL; DR：使用するプロトコルで許可されない限り、できません。

プログラムは常に任意の場所から再開できるわけではありません。たとえば、HTTPリクエストは、サーバーがサポートし、クライアントがそれを実装している場合にのみ再起動可能です。これは普遍的ではありません。サーバーがサポートしている場合、プログラムはプロトコルの一部として単純に尋ねることで転送を再開できます。通常、ダウンロードディレクトリには部分的な転送が表示されます（通常、「。partial」拡張子などが付いています）。

ファイルのダウンロードが一時停止または停止した場合、クライアントはファイルをディスクに書き込むことができ、再開する場所を明確に把握できます。一方、クライアントがクラッシュしたり、ファイルへの書き込みエラーが発生した場合、クライアントはファイルが破損していると見なして最初からやり直す必要があります。BitTorrentは、ファイルを「チャンク」に分割し、どのファイルが正常にダウンロードされたかを追跡することで、これを多少軽減します。再実行する必要があるのは、いくつかのチャンクです。Rsyncは同様のことを行います。

プログラムは、コンテンツが同じであることをどのように知るのですか？1つの方法は、一部の識別子がクライアントとサーバー間で同じであることを確認することです。これのいくつかの例はタイムスタンプとサイズですが、プロトコルに固有のメカニズムがあります。識別子が一致する場合、クライアントは再開が機能すると想定できます。

より明確な検証が必要な場合は、HTTPと友人を最初に選択しないでください。ダウンロードのチェックサムをサーバーのコンピューターのチェックサムと比較できるように、ファイル全体および各転送チャンクのチェックサムまたはハッシュも含むプロトコルを使用する必要があります。一致しないものはすべて再ダウンロードされます。繰り返しますが、BitTorrentはこの種のプロトコルの例です。rsyncはオプションでこれを行うこともできます。

転送に使用されるプロトコルに依存します。しかし、curlはhttpを使用し、ファイルに表示される順序でデータを順番に転送します。したがって、カールは部分的に完了した転送のファイルサイズに基づいて再開できます。実際、長さN（何でも）のファイルを作成し、そのファイルを部分的に完了したダウンロードとして扱うように要求することで、最初のNバイトをスキップするように仕掛けることができます（そして最初のNバイトを破棄します）。