ZIPファイルの破損が発生する原因は？

Question

VC++で、所定のフォルダにあるテキストファイルをフォルダごとZIP圧縮し、FTPにて別PCへ転送し、転送先のPCで、ZIPファイルを解凍するシステムを作っています。
システム運用中に、ZIPファイルの破損が発生し、転送先PCでの解凍に失敗する現象が発生しました。
ZIPの圧縮・解凍はDLLを使用しており、破損の原因がDLLなのか、通信なのか不明な状態のため、原因を特定したいと考えています。

破損したZIPファイルは、基本的には解凍ができず、トライした中では、Lhaplusのみ破損を検知した上で解凍が実行できましたが、解凍されたファイルは一部のみとなっていました。

また、ZIPファイルをバイナリエディタで確認したところ、ファイル内の途中から複数個所で、512バイト分0埋めデータとなっていました。

上記の状況が発生する原因としては、どのようなことが考えられますでしょうか？

原因特定のために、アプローチすべきこともありましたら、ご教示ください。

＜補足情報＞
OS：圧縮側：Windows8.1 64bit
OS：解凍側：Windows7 32bit
開発環境：VS2012、VC++
圧縮ライブラリ：zip32.dll、zip32j.dll
解凍ライブラリ：unzip32.dll

＜追加情報１＞
ZIPファイルは送信後、削除されるため、送信側で破損していたかどうかはわかりません。
DLLでの圧縮時にエラーが発生したかどうかのログも出力していないプログラムのため、現状送信先に破損したZIPファイルが転送された事実しかわかっておりません。

＜追加情報２＞
DLLでの圧縮は、zip32.dllのZip関数に、以下のようなコマンドを渡しています。
「-rq [出力するZIPファイルパス] [フォルダパス] [フォルダ]*.*」
通信に関しては、ソースコードがどうなっているか確認できない状況です。

＜追加情報３＞
システムは、半年ほど稼働しており、送信は1日1回程度ですが、送信側のPCは、数十台あります。
その中で、今回一度だけ発生した現象となります。

Answer 1

こんにちは。

破損したZIPファイル

送信側PCのこれに対応するZIPファイルは破損してないでしょうか?
もし、破損していないのであれば通信で破損したことは確定と思います。dllではなくftp通信部分を疑いましょう。

送信側PCのZIPファイルも破損していて受信側の破損したZIPファイルと一致するようならば圧縮時に破損しています。圧縮プログラムに何か問題がないか確認しましょう。

Comments

[sassan]

ご回答ありがとうございます。
ZIPファイルは送信後、削除されるため、送信側で破損していたかどうかはわかりません。
DLLでの圧縮時にエラーが発生したかどうかのログも出力していないプログラムのため、現状送信先に破損したZIPファイルが転送された事実しかわかっておりません。

[Chironian]

なるほど。手がかりが512バイト単位で化けることしかないのですね。

HDDのセクタは通常は512バイト単位でリード／ライトします。しかし、HDDの故障ならば他にも不具合が出る筈ですので可能性は低いと思います。

ZIP圧縮が512バイト単位で書き込むとか、FTPが512バイト単位で転送する等の情報があればヒントになりそうですが、私はその辺詳しくありません。ごめんなさい。

Answer 2

半年稼働で発生が1回だけとなると、原因の特定が難しいですね。
送信側は転送後ファイルを消してしまうとのことですが、送信前にZIPを解凍してみて正常に解凍できるか確認するようなコードを埋め込んでみてはどうでしょうか？
次発生した時に送信側かどうかの見極めはできると思います。
別途、ファイルのサムかハッシュコードを送る（ファイルに値を書き込んでそれをそのまま送る）様にして、送信側と受信側で一致するかどうか確認するとか、何かチェック用のコードを埋め込んで確認するしかないように思います。

Comments

[sassan]

ご回答ありがとうございます。
おっしゃるとおり、次発生した場合に備えた対策を行う方向での検討もしようと思います。

Answer 3

興味深い事象です。半年に1回とのことなので、原因調査も解消も難航するでしょう。同情します。

以下、推測混じりですが、「私だったらこうする」というのを書いてみます。投機的な調査が必要なので覚悟がいります。

まず、足回りの可能性をつぶします。ほかにディスクエラーが出ていないか確認します。
受信したファイルの更新タイムスタンプをみて期待通りか、つまり、全然別の処理が掴んで上書きしてたよーなんてことがないことを確認します。
アンチウィルス系のプロダクトが入っているなら、バグ報告があがってないかなど、ベンダ情報を調査します。

圧縮・展開処理について、バイト列をメモリ上で圧縮バイト列にしているようならバグの可能性があるでしょう。ファイルを圧縮ファイルに変換するようにしているのであれば、さすがにDLLのバグではないだろうでしょう。追加情報2によれば、いったんは候補から外していいかと思います。

TCPスタックも、IPv4ならもう枯れていると思ってよいかと。

ということで、TCPより上を疑います。FTP部分を自作しているのであればバグの可能性があるでしょう。

再現性が100%ではない場合、マルチスレッドセーフではないというバグを疑います。今回のケースだと、

1. 圧縮側で、複数の圧縮処理が同時に走った
2. 送信側で、複数の送信処理が同時に走った
3. 受信側で、複数の受信処理が同時に走った
4. 展開側で、複数の展開処理が同時に走った ← この可能性は消せる。∵圧縮ファイルがすでに破損している。

FTPのアクセスログのタイムスタンプを眺めて、3が発生していなかったか確認します。アクセス時刻が近くても、送信元が異なっていれば、1. 2. の可能性は消せるでしょう。

残るは3なので、テスト環境をたてて、事前に圧縮したファイルを使い、cURLとか apache JMeter とかを使ってFTPを同時に大量にぶっこみます。原因が 3. だとすればいつか再現するはず、ここで再現できれば勝ちなので、祈ります。

これは経験からですが、1日1回×半年で1回発生した故障の、マルチスレッドセーフでないことが原因だとしたら、長くても3日程度ぶん回し続ければ再現してくれるでしょう。

アクセス時刻が近い足跡がなかったとか、再現しなかったとしたら、さて、どうしましょう……

Comments

[sassan]

ご回答ありがとうございます。
FTPログを入手できていなかったので、確認してみたいと思います。
また、ご提示いただいた検証内容についても、参考とさせていただきます。

Answer 4

その状況では原因の特定は不可能ですし、復旧も不可能かと思います。
・送信元ファイルがそもそも壊れていた
・どこかで誰かが一部を書き換えた
・ディスク障害
・ネットワーク障害
・プログラムの不具合
・FTP転送中にコケた

最後のFTP転送中にコケた場合、似たような状況になった記憶があります。
FTP転送した際に、送信元と送信先でデータが一致しているかどうかの確認は取っていますか？
ハッシュ値等のファイルも一緒に転送すると、何かあった際の原因の追跡の役に立ちます。

Comments

[sassan]

ご回答ありがとうございます。
おっしゃるとおり、現状では原因の特定ができないため、可能性を模索している状態です。
FTP転送中にコケた、というのは、命令は成功したが、実際のデータ転送が正しくいかなかった場合でしょうか？
今回、FTPの処理部がどのようになっているかわからない状態ですが、エラーのログは記録されていませんでした。

Answer 5

この情報だけでは、単にプログラムにバグがあるのでは？ということしかわからないと思います。
最低限、
・原因が圧縮にあるのか通信時にあるのか？
・圧縮や送信部分のソースの概要
だけでもわからないと何が原因かはわかりようがないと思います。

とはいえ、DLLにバグがあるとは思えません。
圧縮時もしくは通信時のファイルの読み込み時の何等かバグがあるのではと思います。

Comments

[sassan]

ご回答ありがとうございます。
＜追加情報２＞として、不十分ですが、補足させていただきました。
DLLのバグではないだろうとのことですが、今回の使い方の場合、ファイル破損の結果となる場合は、ありそうでしょうか？