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