【謎】本当にあったfindコマンドの怖い話【質問編】

※質問受付は終了しました。(3/22) 先にまとめ リネームではinode番号は変わらないけどエントリの位置が変わることがある。 これが一番知りたかった情報。でも文章では理解したけど、検証コードはどう書けばいいかわからん… readdirはアトミックじゃない。読み込み中にエントリ情報が変われば次の読み込みに影響する。 man にも「readdir()は非スレッドセーフです」って書いてある。 fts_readは実行時にreaddirの結果を10万件(ずつ？)キャッシュしていて、途中(たぶん10万件)まではエントリの変更の影響を受けないっぽい。途中からreaddirと同じことが起こる。 ソースコードの斜め読みと挙動を観察した限りそんな感じっぽい。厳密に裏取りしたいけど疲れた。 findコマンドは readdir ではなくそのラッパーの fts_read を使っているので、 fts_read と

[xbs2r]

リンク先で示されていたことは、inode番号ではなくディレクトリエントリ順が変更されるケースの実例でした。虚偽を書いたことをお詫びいたします(編集済み)

[gaudere]

readdir(getdents)の読み出し順はディレクトリエントリの格納順。普通はiノード番号でソートされていない。

[n314]

find、readdir、getdents、iterate_dir、ext2_readdir と順番に降りていって、あとページキャッシュ周りも調べたら正確な挙動が分かりそう。途中からVFSと個々のファイルシステムになるけど。

[honeybe]

「全然詳しくないので教えてやってください＞＜」あ、これ大学教授が「この分野は専門外なので…」っていう奴だ！(本文未読 / 「なるほど」以外言えない(理解してない)

[Nean]

あとでちゃんと読む。む。

[naga_sawa]

未定義なんだ

[zu2]

iノードとファイル名がごっちゃになっているような

[tsutsumi154]

無限findとか考えるやつのほうが怖い

[bottomzlife]

そもそもなんでreaddir()がアトミックだと思えるんだろう…ときどき「ファイルシステムはDBMS！」と叫ぶカルトの亜流かなんかだろうか

[bufferings]

同じこと疑問に思ったから、また何日か後にのぞいてみよっと。