Namazu-devel-ja(旧)

["Yoshinori.TAKESAKO" <takesako@xxxxxxxxx>]

竹迫です。ちょっと前の話になりますが、、、

NOKUBI Takatsugu <knok@xxxxxxxxxxxxx> said:
> 竹迫さんのパッチをとりこみました。どうもありがとうございます。

野首さん、早速パッチを取り込んでいただいてありがとうございます。
いつも迅速に作業しておられるので、とても助かっています。

>>> new IO::File で作成したファイルハンドル $fh が、スコープを抜けたときに
>>> うまくデストラクタが実行されずにファイルをオープンしたままになっている
>>> ようです。やはり ActivePerl においては、明示的に undef もしくは ->close
>>> しておくのが無難のようですね。
>
>  http://bugs.activestate.com/ を簡単に眺めてみましたが、ちょっと見た
>感じではそれっぽい問題は報告されていないようでした。ひょっとすると探し
>かたが悪いかも。

私も探してみたのですが、そのような問題はまだ報告されていないようですね。
その後、簡単なスクリプトを書いて試してみた結果、なぜか、ActivePerl では

unlink $var::NMZ{'status'} if defined get_status($key);

という書き方ではうまくファイルが削除されず、

my $status = get_status($key);
unlink $var::NMZ{'status'} if (defined $status);

のように分けて書くと、うまくファイルが削除できることがわかりました。

もちろん、UNIX上の Perl ではこのような問題は発生しませんし、
get_status() において $fh を明示的に undef もしくは ->close
しておくことでこの問題は回避することができます。

Hideyuki SHIRAI (白井秀行) <shirai@xxxxxxxxxxxxxxxxxxx> said:
>私の WinNT4.0/2000 + ActivePerl 522 でも同様でした。Win32 では
>Documents の数は全く意識しない運用をしているので気付きませんでした。

ご確認どうもありがとうございました。ファイルを追加してインデックスの
更新を繰り返していくうちに Total Documents の数がおかしくなる現象と
いうのは前々から気が付いていたのですが、Win32 ではそんなもんなんだろ
うと、運用に障害がでるほど深刻な問題ではなかったので、気にしないよう
にしていました...<(^_^;

># Ruby で close していない File を mv したときはエラーが出たんで
># すが、Perl だと unlink が出来たように見えてしまうんですね。そ
># れとも、スコープ外に出たからなのでしょうか。

なぜこのような問題が発生するのか、未だ原因はよくわかりません。(^^;
Perl では unlink の戻り値を自分でチェックしない限りエラーを検出で
きないので、これは Perl の良いところでも悪いところでもありますね。

--
   広島市立大学 情報科学部 情報機械システム工学科
     竹迫 良範 <takesako@xxxxxxxxx>