Namazu-devel-ja(旧)

[Yukio USUDA <m6694ha392t@xxxxxxxxxxxxxxx>]

臼田です

Tadamasa Teranishi wrote:
> 
> Yukio USUDA wrote:
> > 
> > tar.pl フィルタを gtar コマンド利用で試してみました。
> > .tar.gz が conf.pl で DENY_FILE にされているのに気づかず少し悩みました。
> 
> 普通は DENY で良いと思いますよ。アーカイブファイルの中身も検索したい
> 人が使えば良いので、デフォルトは検索できない方が良いでしょう。
私もそう思います。

ただ、圧縮していない tar ファイルをあまり見かけることがないので
.tar.gz を処理できるかなと試し、あれと思いました。


> > Tarフィルタで気になった点
> > * eval 'use Archive::Tar'; は filter_archive_tar の中に持っていって
> > 　使用直前まで読み込まないようにしたほうがよいです。
> 
> これは、使わない場合はロードしないことでメモリを無駄に消費するの
> を抑えるためでしょうか? (それ以外に何かありますかね?)
> 
以前 unicode.pl を読み込む部分で野首さんに指摘されました。
メモリ消費の問題だと思っています。

gzip.pl でも使用時に読み込んでいますね。
ただ、MP3.plはモジュールのバージョンチェックをstatusですることにしたため
例外を作ってしまいました。

確かに gzip.plのように毎回 util::checklib で確認するのも気になりますし、
毎回 eval use するのもいくらか負荷があるのではと思います。
読み込んだモジュールを破棄する方法もなかったと思うので
モジュール側で工夫するのはもともと限界がありそうです。

モジュール読み込み時に一回だけ use するほうが素直な気もします。

pl/conf.pl, mknmzrcで
%LOAD_MODULES という変数にモジュール名を羅列して
使用したいモジュールのみ指定して読み込むようにするのはどうでしょうか。
メモリを少しでも節約したいという方は意識的に指定できますし。

> > * gtar と Archive::Tar ならば .tar.gz な ファイルを扱えるので gzipフィルタを
> >   通さずに直接ファイル抽出したほうがメモリ効率がよいかも。
> 
> はい。メモリ効率だけではなくて、オーバーヘッドも減るのでしょう。
> 
Archive::Tar については FAQ を見ると速度も効率もあまり期待できないようですね。
Tar.pmの中は見ていませんが結局メモリ内で生のtar に伸張してから各ファイル
を扱っているのかもしれません。

> > 　（.gz ファイルと .tar.gz ファイルを区別する方法があればですが）
> 
> こちらのうまい方法が見つからないので、今のところ実装していません。
> あまり拡張子で判断するという方法は採用したくないので、別の手がない
> かと思っています。
> 
> また、Ooo と zip の関係がどうなっているのかきちんと調べていない
> のですが、ここでやっている方法が使えるのかなと思っています。
> (拡張子で判断しているのなら、それまでですが...。)
OOo, KOfficeは単なる zipファイルなので magicデータだけでは zipと
区別がつきません。
MMagicで zip であると確定されてしまうので、zipだけはmknmz内で拡張子
とのくみあわせで判別しなおすように直しました。
.tar.gz も対応するならmknmzのファイル判定部を改造するのでしょうが、
gtarがファイルを取り出すとき、メモリ使用量が変わるかどうかによっては
修正する理由がないかもしれません。

> > アーカイブ系フィルタ共通で気になった点
> > * zip, lha, tar で nesting_filter は共通のようなので 外に追い出しては？
> 
> 将来的には gfilter.pl に追い出すのが良いでしょうね。
> 
はい。

> > * 再帰呼び出しのときは拡張子によるファイルのふるい落としがされない。
> >   （適当なtar.gzファイルを試したらC, perlのソースも text/plain として
> > 　　全部コンテンツに入ってきました。）
> > 　mknmz::add_target から該当個所をもらうのはどうでしょう？
> 
> この辺りは mailnews.pl や macbinary.pl にも当てはまることで
> しょうか。
これらも少し直して共通のサブルーチンを使用できる形にしたいですね。

> いずれにしても、もらってくるのが良いと思います。
> 
はい。

> あとは、$FILE_SIZE_MAX のアーカイブ版 $ARCHIVE_SIZE_MAX を追加
> して、アーカイブファイル自体のサイズ上限を設けてはどうかと
> 思っています。
> 
展開前に用心するということでしょうか？
実際に外部プログラムでどのようにメモリが消費されているかは理解していない
のですが、unzip と lha フィルタは一つづつ展開していく形になりましたし、
tarはそもそも圧縮されていないので膨らみようがないと思います。

> ところで、MitakeSearch V4.1 の新機能がアーカイバ対応(それだけじゃ
> ないけど)だったということを今更知りました。流行かな?
> -- 
個人的には大容量ハードディスクが安価になったし、ファイルシステムそのも
のにも圧縮機能がついてきていることから、自分でファイルを圧縮して整理・保存
するという習慣がなくなりました。
どちらかというと流行には逆行しているような気もしますが、展開しなくても
中身を探せるようにしてあれば、違った活用方法がありそうです。

アーカイバ対応だけでなく他製品で実装されていてNamazuでもあるとよさそうな
ものはいろいろありそうですね。

臼田幸生