gzip -tが切り捨てられたダウンロードエラーを100％検出できますか？

想像する：単一の1g CSV.gzがFTPフォルダに記録されています。その間、私のクライアントコンピュータはSFTPを介してフォルダに接続し、そのフォルダをドラッグしようとします。

尋ねる：ファイルを取得したら、クライアント側で取得した見かけの長さに関係なく、部分ファイルを検出し、gzip -t切り捨てが発生した場所に関係なく失敗することはありますか？

解凍または-t'estingは、断片が突然終了したときに可能な切り捨て点の99％でエラーが発生すると思います。しかし、gz構造には、gzipが予期せず成功を報告するきれいな切断点がありますか？

テーブルにない緩和（これらのいずれかが機能している場合は、上記の質問をする必要はありません。）

1. 別のネットワーク要求を介してファイルの長さまたはmd5を取得します。
   1. FTPを介してファイルの長さをポーリングすることは、サーバーが時々zipストリームにブロックを書き込む可能性があるため、あまり良くありません。バッチジョブがファイルハンドルを閉じる前にそれを完全なデータセットとして間違えることは、分析にとって致命的です。
   2. バッチ操作による最終ファイルの長さまたはハッシュを考慮すると、この問題はもう必要ありませんが、これは（この問題に対して）存在しない可能性がある実装負担をチームに与えます。
2. 一日の異なる時間に読み書きをスケジュールしても競合を避けることはできません。
3. サーバーがアトミック移動操作を使用していません。
4. CSV行/列の数は、すべてのスナップショットと統合ごとに変わります。この問題に対してgzipで圧縮されたファイルは、不透明なバイナリBLOBと言うこともできます。
5. ゲームにクライアントがありません => SFTPネットワークエラーです。 （これはキャプチャされ処理されます。私の懸念は、サーバー上でバッチ操作中に時々作成されるファイルを読むことです。）
6. SFTPの代わりにRESTful APIを使用してください。

既存のSOが見つかりません。

いくつかのSOが言及されています。扱う切り捨てられたが、すべての問題に対してワークフロー全体を確実に失敗させる必要があるのと比較して、損失が許容される環境で。 （私は医療データ環境で計算をするので、間違った統計を広げるので、むしろサーバーを止めて火がついたほうがいいです。）

• gzip：予期しないファイルの終わり - ファイルを読む方法正反対です。ユースケースに問題がないため、EOFエラーを抑制しようとしています。
• gzipを使用すると、スクリプトに予期しないファイルの終わりが表示されるのはなぜですか？ちょうどposixストリームの終わりが意図的に挿入されているだけで、head「誤検知は可能ですか？」という内容は扱いません。
• 出力パイピング時のzcat / gzipエラー 非常に近いしかし、「このエラーが発生することが保証されていますか？」と尋ねません。
• 潜在的に切り捨てられる gzip ログファイルのマージまた、終了したバッチジョブの部分ファイルを処理するが、まだ保証されたエラーの代わりに読み取れない行がいくつかあるため、閉じます。