如何有效地搜索文件系统（算法）？答案

【问题标题】：How to search a file system efficiently (algorithm-wise)?如何有效地搜索文件系统（算法）？
【发布时间】：2012-10-11 03:18:08
【问题描述】：

深度优先搜索是搜索文件系统的一种可怕方式——实际上，使用 DFS 可能需要很长时间才能找到可能位于非常接近根目录的目录下的文件，因为 DFS 会分散注意力另一个深层的、不相关的目录层次结构。
然而，它的资源需求非常好——它需要保持打开的文件句柄的数量只与层次结构的深度成正比，而不是它的大小。

广度优先搜索是显而易见的解决方案——它非常快。
（上次我测量时，它与我系统上的 DFS 所用的时间大致相同，大约 8 秒。）

然而，BFS 有其自身的问题——BFS 需要保持打开非常大量目录句柄，可能数百万。（在我的系统上，大约有 100,000 个句柄，这个数字高得离谱。很容易会更多。）

这会导致几个问题：

保持打开这么多句柄不仅会消耗内存（无论如何相对便宜），还会消耗许多其他类型的资源，例如虚拟文件系统（网络、挂载目录等）中文件的句柄，以及可能是其他有限的内核级资源。
它还会给用户带来其他实际问题：例如，一直处于打开状态的虚拟目录不再可关闭！例如，这意味着用户可能无法关闭程序、弹出某些设备或关闭某种外部连接。这种方法可能会出现各种问题。

这样看来，迭代深化才是解决方案。

问题？在实践中它非常慢。
我的麻烦是大型目录（例如 Windows 中的 WinSxS）被重新枚举每个深度级别，即使它们不需要。上次我尝试这个时，迭代加深比我系统上的 DFS 慢了约 15 倍。所以 8 秒的搜索大约需要 120 秒左右，这是不可接受的。

当然，试图跟踪你不应该打开的目录（也许是因为你注意到你不再需要打开它们）通过发现我们所有的资源问题，首先破坏了使用迭代深化的目的。和 BFS 一起吃过。

所以，问题很简单：

如果您正在搜索一个您不熟悉的文件系统，您应该如何着手在速度和可用性之间实现可接受的平衡？有比 BFS 更好的选择吗？

【问题讨论】：

致我刚刚拒绝编辑的人：我想我可能误读了您的编辑；我确实有一个错字。如果我搞砸了，请道歉。

标签： language-agnostic filesystems depth-first-search breadth-first-search iterative-deepening

【解决方案1】：

如果您真的对文件的位置没有任何指导，那么我认为您无能为力。您应该尝试使用一些技巧来最小化搜索和搜索时间，但是文件系统会变得支离破碎，您无法知道这一点，因此很难在那里做很多事情。在许多文件系统上，在搜索子目录之前搜索目录中的文件应该更快，特别是如果您正在寻找可能已内联的小文件。使用完整的 BFS 不耗尽内核资源也是一件好事。

即使您只知道文件可能在哪里，这也有很大帮助。例如，如果它是用户放在某处然后忘记位置的文件，则从主目录、临时目录和驱动器的根目录开始，并执行 DFS，直至达到合理的递归限制（例如 6- 8 会在我的 Windows 或 OS X 机器上找到任何手动放置的文件或自动下载的文件），其理论是用户通常不会意外地得到深树，但自动生成的层次结构可以变得很深。如果该搜索失败，请返回并搜索您之前跳过的深层目录。如果文件丢失了，无论如何搜索都会很慢，因此请退回到 DFS 以确保安全，并且不会在用户继续使用机器时造成太多问题。

最重要的是，如果系统有任何类型的搜索索引，请先检查它，即使这意味着要编写更多代码来支持它。

【讨论】：