リモートの転送元ファイルが変わった場合に再試行する

dosyaは転送前に転送元を事前確認し、完了まで同じオブジェクトであることを前提とします。範囲ジョブはIf-Rangeを通じて強いETagを送信します。206を想定したところ200のレスポンスが返された場合、検証情報が一致しなくなったことを示します。ストリームモードでも受信したバイト数を事前確認時のサイズと比較します。

始める前に

ダウンロード元のサーバーでファイルが変更されましたは終了した状態として扱ってください。dosyaは部分オブジェクトを片付け、2つのリビジョンのバイトを混ぜて転送を続けることはありません。

署名付きURLでも、提供元が同じアドレスの内容を再生成すると、内容が変わる可能性があります。変更されないバージョンのURLか、転送中ずっと内容が変わらない新しいエクスポートを選んでください。

手順

1. 失敗した行のファイル名、予定された合計、進捗を記録し、転送元を確認する間は行を表示したままにします。
2. dosyaのジョブ開始後にオブジェクトが置き換えられた、再生成された、切り詰められたか、またはまだアップロード中だったかを転送元の所有者に確認します。
3. 転送元ファイルの作成を完了し、変更されるエンドポイントを再利用せず、最終バージョンに紐付いた新しい公開HTTPS URLを取得します。
4. URLを非公開でテストし、2回のリクエストで報告される合計が変わらないことを確認します。範囲リクエストに対応する転送元は合計と強いETagを伴う206を返す必要があります。
5. 意図したフォルダーに向けて新しいリモートダウンロードジョブを開始します。失敗した行には部分データから再開する操作はありません。
6. 完了を確認し、保存されたバイト数を最終的な転送元と比較してから、終了した行のXで古い行を消します。

期待される結果

新しい転送はゼロバイトから始まり、1つの転送元リビジョンだけから全体が転送されます。変更されたジョブの部分データがdosyaのファイルになることはありません。

提供元が同じURLを継続的に書き換える場合は、完成したオブジェクトをローカルにダウンロードしてからdosyaでアップロードしてください。不安定なアドレスに新しいリモートジョブを送ると、同じエラーが再発することがあります。

関連ガイド

• リモートダウンロードの問題を解決する
• リモートダウンロードを開始する