Namazu-devel-ja(旧)


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tar.pl 作成



寺西です。

Yukio USUDA wrote:
> 
> gzip.pl でも使用時に読み込んでいますね。

そうですね。

> ただ、MP3.plはモジュールのバージョンチェックをstatusですることにしたため
> 例外を作ってしまいました。

話がそれますが、MP3.pl は 2箇所で use MP3::Info していますね。
これってどうなるのだろう。(filter() の方は無意味なのかな?)
 
> pl/conf.pl, mknmzrcで
> %LOAD_MODULES という変数にモジュール名を羅列して
> 使用したいモジュールのみ指定して読み込むようにするのはどうでしょうか。
> メモリを少しでも節約したいという方は意識的に指定できますし。

モジュール単位で調整するというのは、少々大変かなと思います。

どちらかというと、どのフィルタを読み込むかどうかを指定する方が
良いのではありませんか?
エンドユーザには、まだその方が分かりやすいですから。
(また、フィルタの選択という観点でも、何らかの仕組みが必要そう
ですし。)

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

そうなんです。gtar 版とどちらが速いかは環境にも依存するのではない
かと思います。

> Tar.pmの中は見ていませんが結局メモリ内で生のtar に伸張してから各ファイル
> を扱っているのかもしれません。
 
gzip 伸張には IO::Zlib が使われるようですが、メモリに伸張した
tar ファイル全体が置かれることはないものと思います。
 
> OOo, KOfficeは単なる zipファイルなので magicデータだけでは zipと
> 区別がつきません。

はい。gzip ファイルと tar + gzip も同様です。

> MMagicで zip であると確定されてしまうので、zipだけはmknmz内で拡張子
> とのくみあわせで判別しなおすように直しました。

そうですか。
まずは ooo でチェックし、ooo でなければ zip をチェックしてという
ような多段のチェックを行うような仕組みではないのですね。

> .tar.gz も対応するならmknmzのファイル判定部を改造するのでしょうが、
> gtarがファイルを取り出すとき、メモリ使用量が変わるかどうかによっては
> 修正する理由がないかもしれません。

gzip.pl + tar.pl で使えなくもないですから、多段チェックの仕組みを
考える時の、課題にでもしましょうか。
 
> > >  mknmz::add_target から該当個所をもらうのはどうでしょう?
> >
> > この辺りは mailnews.pl や macbinary.pl にも当てはまることで
> > しょうか。
> これらも少し直して共通のサブルーチンを使用できる形にしたいですね。

そうですね。共通化できれば良いですね。
 
> > あとは、$FILE_SIZE_MAX のアーカイブ版 $ARCHIVE_SIZE_MAX を追加
> > して、アーカイブファイル自体のサイズ上限を設けてはどうかと
> > 思っています。
> >
> 展開前に用心するということでしょうか?

アーカイブファイルに含まれる個々のファイルのサイズチェックは
行っていますので、それで十分かもしれませんが、巨大な tar ファイル
(実際には tar + gz でしょうけど)もたまにはあったりします。
# ハードディスク丸ごとバックアップしたものとか。

そのような巨大な tar ファイルの中身までチェックしたくないといった
ニーズがあるかなと思っています。

アーカイブファイルを $FILE_SIZE_MAX でチェックすると、それは
あまりにサイズが小さいかと思うので、別変数 $ARCHIVE_SIZE_MAX で
チェックしてはどうかなと考えています。

# しかし、gzip.pl はアーカイブファイルを考慮していないので、
# $FILE_SIZE_MAX でチェックしているので、ちょっと問題かな。
# やはり gzip + tar をまとめて処理する必要があるかな。

> どちらかというと流行には逆行しているような気もしますが、展開しなくても
> 中身を探せるようにしてあれば、違った活用方法がありそうです。

用途によっては、CAB ファイルとかもニーズがあるのかもしれませんね。
(アーカイブファイルに入っているファイル名検索用途なら)
 
> アーカイバ対応だけでなく他製品で実装されていてNamazuでもあるとよさそうな
> ものはいろいろありそうですね。

おいしそうなものはパクっちゃいましょう。
-- 
=====================================================================
寺西 忠勝(TADAMASA TERANISHI)  yw3t-trns@xxxxxxxxxxxxxxx
http://www.asahi-net.or.jp/~yw3t-trns/index.htm
Key fingerprint =  474E 4D93 8E97 11F6 662D  8A42 17F5 52F4 10E7 D14E