我正在尝试找到一个文件不存在于我的主目录和所有子目录中。
find ~/ -name "bogus"几秒钟后给我这个信息，但是KDE 的dolphin文件管理器做同样的事情大约需要 3 分钟。这与我之前的经验相符侏儒beagle。
如何find在图形搜索（比命令行参数使用更直观）落后的情况下快速完成相同的任务？
答案1
具体来看 Dolphin 和 Baloo，它似乎会查找其搜索域中每个文件的元数据，即使您正在进行简单的文件名搜索。当我跟踪该过程时，我看到对每个文件甚至file.so条目的调用lstat，getxattr并再次调用。这些系统调用检索有关文件的元数据，该元数据存储在与文件名不同的位置（文件名存储在目录内容中，但元数据存储在getxattr..索引节点）。多次查询文件的元数据很便宜，因为数据将位于磁盘缓存中，但查询元数据和不查询元数据之间可能存在显着差异。
find聪明得多。它试图避免不必要的系统调用。它不会调用，getxattr因为它不基于扩展属性进行搜索。当它遍历目录时，它可能需要调用lstat不匹配的文件名，因为这可能是要递归搜索的子目录（lstat是返回文件元数据的系统调用，包括文件类型，例如常规/目录/符号链接/…）。但是find有一个优化：它知道一个目录有多少个子目录链接数lstat，一旦它知道它已经遍历了所有子目录，它就会停止调用。特别是，在叶目录（没有子目录的目录）中，find仅检查名称，而不检查元数据。此外，某些文件系统在目录条目中保留文件类型的副本，因此如果这是它需要的唯一信息，find甚至不需要调用。lstat
如果您find使用需要检查元数据的选项运行，它将进行更多调用，但如果不需要该信息，lstat它仍然不会对文件进行调用（例如，因为该文件被先前的条件排除）lstat与名称匹配）。
我怀疑其他重新发明find轮子的 GUI 搜索工具同样不如经过数十年优化的命令行实用程序聪明。如果您“到处”搜索，Dolphin 至少足够聪明，可以使用定位数据库（但用户界面中不明确的限制是结果可能已过时）。