在文件搜索期间更新进度条
此问题提供了一种使用kernel.dll以递归方式查找文件属性（例如文件名）的快速方法。 问题是报告进度（例如在Windows窗体应用程序中）仅限于当前所在的文件或目录，因为它没有关于预先计算总文件数的信息。
虽然，我知道在Windows 7中如果使用文件浏览器搜索文件，它会显示搜索的进度条：
那他们怎么在这里呢？ 这里的总文件数是否已知？ 是否有可能在上述相关问题的答案中模仿这种进展报告？ 如果没有完整的文件计数，我不知道如何做到这一点。
我能找到的最接近的问题就是这个这个递归方法似乎存在一些问题，因为我没有预先计算文件夹数，并且对于许多文件的单个目录，行为会很奇怪。
根据您需要获得的准确程度，可能会有一个简单的双程解决方案（对于网络驱动器来说不是最佳解决方案，因此您可能需要在那里进行调整）。
对于前n级别的目录（比如4个，包括驱动器），计算子目录的数量。 这通常是一个快速操作，虽然你可以调整它只是在超过5个子目录存在或类似时递归。 存储此号码。
在执行实际搜索时，请跟踪已完成的子目录数，这些子目录位于根的n步骤内。 使用此数字和存储的计数来估算完成情况。
例如，具有基本结构：
C:\ a\ 1\ i\ ii\ iii\ 2\ 3\ b\ c\
计数a ， 1 ，忽略i和兄弟姐妹，计数2等。然后，在搜索时，在完成搜索3,2,1， a等时增加条形。
现在，这绝对不是万无一失的。 可能存在竞争条件，它不是非常准确，还有其他各种各样的东西。
但是，对于低粒度进度条，它足够接近它看起来非常准确。 更重要的是，从用户体验的角度来看，使用存储的计数并将进度与进度进行比较往往会阻止条形图在整个过程中生长。
我实际上在这里的一些代码中使用这种技术。
最初的构建，降低了10个级别，仍然非常快。 我不记得测试了多少测试，但是在搜索2.5-3百万个文件时（尽管只提前检查了1/1000个文件），条形图明显准确而没有多次暂停。 请注意，进度条越短，显示的越准确。 ;）
在后台启动一个线程，计算您正在搜索的目录下的文件。 在后台，更新到目前为止计算的文件数。 在进度条中使用此计数。 一旦此计数大于1，就可以安全地开始搜索。 当计算进度时，如果您的搜索（奇迹般地）超过您的背景文件计数器，或者进度条中的偶然可见离题是不可接受的，则捏造结果。
然后，这就找出了计算文件的最快方法（考虑FindFirstFileEx）。 在本地驱动器上，可能需要2或3秒来计算像Program Files这样的文件夹。 通过网络，它将花费更长的时间，因为使用FindFirstFileEx时，只需要文件计数和目录列表就会传输文件名。
这一切都假定您将在搜索中花费更多时间，而不仅仅是计算文件。