テクノロジー · 実用ガイド
Gzip の「unexpected end of file」―再展開する前に受信バイトを証明する
EOF はダウンロードの欠落、ストリーム中断、または分割ファイルの一部を単独で読んだ結果かもしれません。実物を保存して検証し、本当に壊れた転送経路を直します。
「gzip: unexpected end of file」はデコンプレッサーが早すぎる終端に達したことを示すだけで、原因までは示しません。tar のオプションを変えても届かなかったデータは戻らず、数個のファイルが展開できても部分アーカイブを信頼できることにはなりません。
151,552 バイトの決定的なペイロードから gzip メンバーを作りました。完全な 514 バイト版は展開でき、末尾 8 バイトのトレーラーを削ると EOFError になりました。257 バイトの第1分割片も EOFError、第2分割片だけでは gzip ヘッダーではありませんでした。2片を正しい順序で連結すると元の 514 バイト SHA-256 とペイロードハッシュが完全に再現されました。
この制御実験は診断手順の根拠であり、復旧保証ではありません。未知のファイルは途中破損、変動 URL、不完全生成、複数の有効メンバーの連結、別形式の外包みもあり得ます。失敗したバイトを保存し、可能なら提供元のチェックサムやサイズを取得してください。
再試行前に失敗物を固定する
ファイルを新しい証拠パスへコピーし、バイト数、SHA-256、URL またはオブジェクトキー、応答ヘッダー、取得時刻、全分割名を記録します。再ダウンロードで上書きすると不安定な転送を示す差分が消えます。
コピーに gzip -t を実行し、終了コードと標準エラーを保存します。途中まで展開できたことを成功とせず、ストリーム全体の整合性を読みます。不信入力は隔離作業ディレクトリで扱い、自動展開を避けます。
取得、ストリーム、分割、生成元を分ける
ダウンロードでは受信サイズとハッシュを提供元の署名済みまたは認証済みメタデータと比較します。プロキシの HTML 応答、早期終了した range、互換性のない再開追記を確認し、新名で再取得してから比較します。
ストリームでは転送完了と展開エラーを両方記録します。Node.js の事例は同じ S3 オブジェクトで失敗位置が変動しました。これは完了通知、再試行、オブジェクト同一性を調べる理由であり、大きな gzip が無効という証明ではありません。
検証済み一覧がある場合だけ分割片を戻す
提供者が split を使ったなら、各片、期待サイズまたはハッシュ、並び順を棚卸しします。Unix & Linux の例では part.000 は1本のストリームの前半なので、順番に連結してからでなければテストできません。
連結結果は別ファイルへ書き、分割片を上書きしません。信頼できるチェックサム、gzip -t、実利用の順で検証します。gzip の合格は gzip 整合性だけで、期待したアプリ記録や tar メンバーの存在までは証明しません。
信頼できる元バイトが無いなら止める
一部ファイルが出たことを理由に受け入れたり、合格するまで末尾を削ったり、エラーを隠したりしないでください。見える失敗が無言の欠落に変わります。提供者や上流処理から新しい不変オブジェクトとチェックサムを取得します。
修復後は旧新ハッシュ、転送または連結の変更、gzip 全体テスト、下流検証を記録します。未解決点を明示し、権威ある元ファイルが無い出力は完全ではなく部分結果と表現します。
