zipのCRC

とりあえず、WebDAVにファイルを置いてると、やっぱちょっと想定から外れているのかCRCの計算がめんどくさいです。
CRC算出するためには、どうしてもファイル全体が必要なので、結局、アプリ側でもファイル全体を一旦読まないといけなくなります。
順番に処理できるようになるし、出力されるzipをバッファするわけでもないので、メモリ的にはぐっと楽になりますが、まあなんか格好わるいです。

ちなみに、PythonでCRCを計算するのは以下のような方法でやっています。

crc = ('%08X' % (zlib.crc32(buffer) & 0xffffffff,)).lower()

とりあえず、素直にzlibで計算して、ASCII化しているだけです。これもたぶんもっと速い方法とかあるんだろうなぁ、とかおもいつつですが。

そこで、mod_zipを見ると、CRCに"-"を指定すればCRCを算出しなくともzipを生成すると書かれています。
これを試してみたんですが、Windows標準ツールやzipコマンドでは、CRCが違うよと警告されつつも、ファイルを解凍できるのでが、
とりあえず、Macのアーカイブユーティリティではエラーとなって解凍できないファイルが生成されてしまうようです。
zipの仕様的には問題ないようなのですが、strictにCRC32をチェックするツールが結構あるので今のところ、この方法はあまり使えない感じです。

というわけで、このままは微妙すぎるので、今後は２つのどちらかの解決方法を採ろうと思っています。
・そもそも今回の場合、CRC計算もmod_zip側でやって欲しいので、mod_zipを改造して、たとえば"+"を指定すれば計算するモードを追加する改造をする
・WebDAVへのファイル保存時にそもそもCRCを計算して先に、ファイルとともに保存しておく

mod_zipを改造すると、
メリット　→　既存システムに全く影響がない、CRC計算をCPUが比較的空いているリバースプロキシ側で行える
デメリット→　改造としては結構めんどくさいのと、バージョンアップごとにパッチを作り続けないといけない可能性がある（取り込んでくれればいいけど）

WebDAVにCRC保存するようにすると、
メリット　→　mod_zipに改造を加えなくていい、ファイル破損チェックに他の場面でも使える
デメリット→　既存システムの割と根幹ぽいところをいじる必要がある、そもそもファイル保存をフックして毎回CRC32を計算すると結構負荷が高い？

という感じでどっちにするかはなんとも言えないところです。
んー、すこし悩んでみて、実装してみよう。