ファイルを見つけようとしています。いいえ私のホームディレクトリとすべてのサブディレクトリに存在します。
find ~/ -name "bogus"数秒後にこのメッセージを送ってください。しかし、KDE用dolphinファイルマネージャ同じことをするのに約3分かかります。これは私の以前の経験と一致しています。小人beagle。
findグラフィカル検索（コマンドライン引数よりも使用がより直感的です）より遅れている間、同じ操作をすばやく実行できますか？
ベストアンサー1
具体的には、DolphinとBalooを見てみると、単純なファイル名検索を実行しても、検索ドメイン内のすべてのファイルのメタデータを見つけるようです。プロセスを追跡すると、file.so各ファイルとアイテムへの呼び出しが引き続きlstat表示されます。getxattrこれらのシステムコールは、ファイル名とは異なる場所に保存されているファイルのメタデータを検索します。ファイル名はディレクトリの内容に保存されますが、メタデータはgetxattr..インデックスノード）。ファイル内のメタデータを複数回照会することは、データがディスクキャッシュにあるためコストがかかりますが、メタデータを照会することとメタデータを照会しないことにはかなりの違いがある可能性があります。
findはるかにスマートです。不要なシステムコールを避けたいと思います。getxattr拡張属性に基づいて検索しないため、呼び出されません。ディレクトリに移動するときは、lstat一致しないファイル名を呼び出す必要があります。これは、再帰的に検索するサブディレクトリである可能性があるためです（lstatこれは、ファイルタイプを含むファイルメタデータを返すシステムコールです（例：汎用/directory/symlinks）。/…）。しかし、find最適化があります。ディレクトリにいくつかのサブディレクトリがあるかどうかを知っています。リンク数lstat、すべてのサブディレクトリを通過したことがわかったら、呼び出しを停止します。特に、リーフディレクトリ（サブディレクトリのないディレクトリ）ではfind名前だけを確認し、メタデータは確認しません。また、一部のファイルシステムはディレクトリエントリにファイル形式のコピーを保持するため、findこれが必要な唯一の情報である場合は呼び出す必要はありません。lstat
メタデータ検証を必要とするオプションを使用して実行すると、より多くの呼び出しが発生しますが、その情報がfind不要な場合（たとえば、名前と一致する以前のlstat条件によってファイルが除外されたため）、ファイルへの呼び出しはまだ行われません。 。lstat。
find私は、車輪を再作成する他のGUI検索ツールは、数十年にわたって最適化されたコマンドラインユーティリティほどスマートではないと思います。 Dolphinは、少なくとも「すべての場所」を検索する場合、位置データベースを使用するのと同じくらい賢いです（ただし、ユーザーインターフェイスで明確ではないという制限は、結果が最新ではない可能性があることです）。