[FDclone-users:00611] Re: 仕切り直します。

[Takashi SHIRAI <shirai@unixusers.net>]

　しらいです。

In Message-Id <20061005200424.362567.80c00eec@isis.ocn.ne.jp>
        yuji tamura <yuji@isis.ocn.ne.jp>さんwrites:
> こんばんは、田村です。

> いつも拙い確認報告でご迷惑をおかけします。
> 言葉も悪いのかもしれません。

　私もちゃんと読んでいないところがあったようですみません。何
せこちらでは全然再現しないもので、解決には田村さんの環境だけ
が頼りなのです。


> >>と言うディレクトリ名が消える現象は確認しました。
> 
> >ほぅ消えましたか。
> 
> の事でしょうか？、すみません、ファイル名が消える現象は
> 変わりませんよ、と言いたかったのでした。

　症状が消えたのかと誤読してしまっていました。ふむ、この箇所
は関係なさそうですね。


> でいいしょうか？、素の fd v2.09 に上の変更をしただけの物で
> 検証しました。
> 「/Users/yuji/Documents/」において
> 「1 shopping/」と言うディレクトリ名が消える事を確認しました。

　ううむ、となると buffer overflow によるトラブルという訳で
はなさそうですね。
　GNU malloc の trace 機能を使って Log 解析もしてみたんです
が、malloc()/realloc() と free() との対応付けも問題なさそう
でした。
　となると、一旦 free() した筈の領域に何か書き込んでしまって
いるんでしょうかねー。


> > 　directory 内の file が多いとそれだけ大量の strdup2() が実
> > 行されるので、ある程度の数が必要になるのでしょう。
> 
> なるほど、数の方が問題になるのですね、サイズの方かと思ってました。
> 検証して見ます。

　file size は中身を参照して初めて効いてくる要素なので、file
name を参照しただけで出て来る症状には関係ないと思います。
　size で言うなら file name の長さが効いてくるでしょうか。こ
の長さと数とで、file name に使うメモリ領域のサイズが増大しま
すから、それを合わせないと再現しないかも知れません。
　directory entry の順序も効いて来る可能性があるので、厳密に
再現しようとすると ls -f の結果を示して貰わないといけないで
しょうね。


> > 　再現可能な directory 構成が構築出来たら、その構成を tar に
> > して添付して下さい。file name だけの問題なので、file size を
> > 全部 0 にすればそんなに大きな tar ball にはならないでしょう。
> 
> こちらも確認中ですがもう少し時間がかかりそうです、もう少し時間を
> ください。

　まずはこの環境を何とか用意してみて下さい。その上で、同じ環
境をあちこちに再現して、症状の再現性を検証したいと思います。

                                               しらい たかし