[Namazu-win32-users-ja 1249] Re: mknmzの処理が中断する

Tadamasa Teranishi yw3t-trns @ asahi-net.or.jp
2010年 9月 17日 (金) 22:56:12 JST


寺西です。

ホクコン 設計 小川 点 wrote:
> 
>   私のところも半年以上前からインデックスを作成しており、非常に苦労してい
> ます。また、多大な時間も使っています。(データ量が多いので)

ヒント $ON_MEMORY_MAX
 
> 1、まず、インデックスを格納するフォルダー名ですが、これは、もろに漢字に
> 影響します。使うとハンぐるフォルダー名漢字は、たくさんあります。また、

インデックスを保存する場所をわざわざ日本語を含むパス名にしなくても
問題ないでしょう。

> WindowsサーバーとローカルWindowsでは、状況が若干変わるようです。(信じら
> れませんが)

ん?
よく分かりませんが、ファイルシステムが NTFS と FAT32 で違うとかという
オチなんでは?

> で、原因は、長いファイル名の最後のフォルダー名が 表 でした。この漢字は、

だから、「表」は2バイト目が 0x5C だからですって。

0x5c は '\' つまりパスの区切り文字と同じなので、Shift_JIS 系の文字を
意識しない処理だと、そこでアウトになるんです。

> 除して実行した場合は、すんなり、通ります。結果的には、表 を 図表に変更
> して動きました。(これも理論的には、信じられない)

「表」を含む以上、正しい結果は期待できません。
動いたとしても、きちんと処理できていない可能性が高いです。

パス名が長かろうが短かろうが関係ありません。「表」を含めば、短くても
問題が生じる可能性は非常に高いです。
# 何んせ2バイト目が 0x5C だから。

他にも「能」とか「噂」とか、いっぱいあります。

> で、言いたいのは、漢字コードだけではないです。フォルダー名の長さ(深さ)
> や、全体のデータ量に大きくかかわっているとしか思えません。というのが半年
> 以上、苦労してきたところの結論です。

どっから、そんな結論になったのやら?
あからさまに漢字コードの問題でんがな。

>  自分もプログラムを作りますが、Perlは、どうも理解できないんで、やってい
> ません。おそらく、メモリリークかなんかじゃないのだろうかというのが、現時
> 点での思い込みです。

ほんとに滅茶苦茶な思い込みです。
メモリリークとどんな因果関係があるのやら??
  
> 階層を深く潜っていって、こまかくインデックスを作成し、順に、mkmergeで、
> 大きなインデックスを作成するという自動処理をおこなっています。mkmergeに
> もっとたくさんのインデックスを指定できるようにしてもらうと、時間的なロス
> が大きく改善されると思いますね。(あくまで、私のやり方の場合ですが)

マージしなくても最大 64 個までのインデックスは検索できますが?

# 64個指定するのは大変だから、実際 64 個まで使えるかは微妙だが...。
-- 
=====================================================================
寺西 忠勝(TADAMASA TERANISHI)  yw3t-trns @ asahi-net.or.jp
http://www.asahi-net.or.jp/~yw3t-trns/index.htm
Key fingerprint =  474E 4D93 8E97 11F6 662D  8A42 17F5 52F4 10E7 D14E


Namazu-win32-users-ja メーリングリストの案内