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

3/21 22時頃: 質問編へのリンクを撤去し、タイトルを変更しました。(元のタイトルは「【謎】本当にあったfindコマンドの怖い話【解決編】」) 昨日のエントリについて、実験にしてはケースが雑だったので再検証していきます。 【謎】本当にあったfindコマンドの怖い話【おもしろ現象】 - くんすとの備忘録 ちなみにモチベーションは「問題を回避したい」ではなく「この現象の原因を知りたい」です1。 よろしくお願いします。 現象からしてfindコマンドが処理中に書き換えられたファイルを読み込んでいるのは明白です。 少しずつ仮設を立て見ていきましょう。 まぁまぁお付き合いください。 検証ケース ケース1: 10万ファイルで実行 ケース2: パイプを使わずfindコマンド一発にし、100万ファイルで実行 ケース3: ケース2を10万ファイルで実行 ケース4: ケース2を15万ファイルで実行 ケース1

[ryuichiueda]

「パイプを外しても二重読みは発生するようです。 パイプ関係なかったっすね。」穏やかに怒っておられる。

[megumin1]

現象の原因をいまだに筆者はまったく理解していない。解決にもなっていない。パイプ等で同時に起動された2つ以上のプロセス(findとmv)がお互いにファイルロック(flock(2))等で排他制御していない以上、防ぎようがない。

[OkadaHiroshi]

blog主は解決策には興味がないみたいだけど、読者の中には解決策に興味がある人もいるかもなので一言。 moreutils の sponge を使うと便利。 find xxx | sponge | xargs yyy みたいに。

[uva]

ワロタ。結局、1つ前のエントリのブコメで本当の原因に言及した人はおらず、それどころか正しくない推測に対して検証も訂正もせずに書きっ放し。しかもそれを読んでわかった気になってる人もいるし地獄やな

[craftone]

検証せずにコメントしました。ごめん！／inode変わってないはずなのに二重読み込みされるの気になってるがreaddir()を斜め読んでもよく分からん。。

[snowcrush]

前回パイプについて指摘していた人たちが言っていたのは"command1 | command 2" を "command1 > /tmp/hoge; command2 < /tmp/hoge"に変えろという意味だったんじゃないのかな。-execだと結局変わらんような。

[tumo300-500]

`「問題を回避したい」ではなく「この現象の原因を知りたい」` って最初に書かれてるやん

[kazuau]

POSIXのfind(1)の仕様に対象ディレクトリにファイルが追加削除される場合の動作は不定だと明記されてるので仕様通りであり、そもそもreaddirの挙動がファイルシステム依存だからたぶん当然のことなんでしょう。

[diffie]

「現象からしてfindコマンドが処理中に書き換えられたファイルを読み込んでいるのは明白」って最初の記事に書かなかった時点で、ああいう答えが返ってくるに決まってるじゃん。そして負けず嫌いな人。

[ledsun]

「readdirが（性能上の理由で）ロックしていない」に対して、findはキャッシュして対応している。上限は10万。では、なぜ10万1や20万1ではなく、15万という半端な数字に境界があるのか？

[pmint]

何が解決したんだろう。これで分かった気になれるのが怖い。ケース1のログをこっそりソートしてる点や、バッファーを10件にしたのに1000件正常に処理できたことを看過してる点はなんなの。

[UDONCHAN]

へーへー

[pattyhama]

面白い

[hazisarashi]

はてブまじ怖い。

[yoshikidz]

本当の原因はなんなんだろう。どうやってキャッシュしているかのkeyに問題がありそうだけど、inodeとか使ってるのかねー。 検証してる人 みとこw find特有の問題ならいいんだけど、依存関係あると面倒よね

[Akimbo]

知識はありそうな筆者がソフトウェア開発の基本のキを全く理解してないらしいとこに頭を抱える。要するに「出力が入力を書き換える可能性がある設計は避けるべし」で、ドヤ顔で出したワンライナーのバグなんですよ。

[webarata3]

"一度に読み込む量が定数だからでは。"

[vndn]

findの挙動の原因よりもなぜワンライナーで書くのかの方が気になる。

[toritori0318]

ブコメでspongeコマンドを知りました。へー

[ton-boo]

パイプ前段の処理内においてどのタイミングでstdoutするかによって挙動が変わる（つまりうまくいくケースもある）のは当然なのでもにょりながら見てたけど、moreutilsのspongeの存在を知ることができたのでよかった

[mobius118_7]

解決する方法はいくらでもある。findの動作検証が目的なんだからこの記事は正しい。でも根本的な原因わかってない

[cartman0]

コマンドの細かい挙動結構わからんし、どんどん啓蒙記事増えるべきやね

[Nyoho]

この一連の流れ、勉強になる。

[uehaj]

なんか理解が甘いような。ブログ主が期待する動作をするためには、ディレクトリ中のファイル名一覧情報のスナップショット化機構が必要だが、現実には存在しないってだけの事。findの問題というのも不適切

[sugawara1991]

いやその、パイプそのものが問題とかそういう話じゃなくて、ディレクトリの書き換え側と読み取り側が並列動作することによる競合状態が本質なのであって/DOSで起きないのは前段プロセスが閉じないと次に行かないから

[tockri]

なるほどー。10万個ずつファイルを走査してるから次の10万個の時に処理済みのファイルが入っちゃうのね。おもしろい。

[shikiarai]

また一つ賢く……10万ファイルも扱わねぇな

[tettekete37564]

普通にイテレーション中にインデックス変わるような操作したらそうなったりするもんでは？この場合はファイルアロケーションテーブルの。リネームじゃなくて別ディレクトリへの移動なら起こらなそう

[mn_kun]

なんで可能性の指摘に対して怒ってるのか

[dirtjapan]

検証されてて面白かった。ディレクトリの一覧がファイルシステムによってキャッシュされててそこ次第かな。解決策は別ディレクトリに出力するしかないよね。なんとかしたい気持ちはわかる。

[oktnzm]

労多くして・・・

[masatomo-m]

二つのプロセスが同時に実行しないように間にblockするuniqコマンドとかを挟めば良いのでは、とか思ってた。パフォーマンスは落ちるけど確実にfindが終わってから次の処理に移るので

[tamtam3]

シェル芸は悪い文明…内部で桁落ちしてそうだが洗い出すほどの情熱はない。すまない

[naga_sawa]

回避策は色々あるとして/裏でディレクトリ内容が変わった場合のreaddir()の挙動はどうなってんだろう/mv後のエントリを拾い続けて無限ループになりそうだけど/未定義？/未定義と http://yarchive.net/comp/linux/readdir_nonatomicity.html