検索を使用してフォルダを削除する - 奇妙なメッセージ

イベントの正確な順序は次のとおりです。

1. 作るfoodir
2. 放射find
   1. findは現在のディレクトリを読み取り、結果をキャッシュしてから繰り返してfoodirのエントリを見つけます。
   2. execfindはfoodirコマンドを開始し、foodirを削除します。
   3. find は、もはや存在しない foodir (find の内部キャッシュにある) に再帰しようとします。
   4. findはfoodirに再帰できないという警告を表示します。
   5. findは次のエントリに続きます（この場合はおそらくディレクトリエントリのリストの終わりなので、最善を尽くして操作を実行した後に終了します）。

だからあなたが見ているのは外部の観点からはやや予想外のことですが、完全に説明可能です。

キャッシュはほぼ確実にパフォーマンスを向上させ、ファイルあたりの潜在的なシステムコールを大幅に削減し、潜在的なディスクI / Oを大幅に節約するために行われます。トランザクションファイルシステム（通常は保証されていません）がない場合、findが各エントリに対して一度ディレクトリを読み取っても、特にローカルでないファイルの場合、この問題は発生しないという保証はありません。システム、さらに注文するエントリ数は確認の間に変更される可能性があるため、単にインデックスを追跡することはできませんが、訪問するすべてのディレクトリエントリを追跡する必要があります。大規模なディレクトリ階層では、これは禁じられています。

一般的に言えば、これは」競争条件": 計算の前提条件は、計算完了と結果値の使用の間で変更されます。

GNU findのマニュアルページを見ると、-ignore_readdir_race警告を表示しないようにするオプションがあります。しかし、これがfindを介して実行される他のコマンドにどのように役立つかはわかりません。必要に応じてこれで十分かもしれません。標準エラーを/ dev / null（コマンドラインに追加）にリダイレクトしてfindにエラーや警告を表示しない可能性がありますが、2>/dev/nullより深刻なエラーを隠す可能性があるため、この方法はお勧めできません。また、これが呼び出されるコマンドのエラー出力とどのようにやり取りするのかわかりません。