5

我一直在试图弄清楚如何使用 python 检索（快速）给定 HFS+ 驱动器上的文件数。

我一直在玩 os.statvfs 之类的东西，但什么都得不到（这对我来说似乎有帮助）。

有任何想法吗？

编辑：让我更具体一点。=]

由于各种原因，我正在围绕 rsync 编写一个类似时间机器的包装器，并且希望非常快速地估计（不必是完美的）驱动器 rsync 将要扫描的文件数量。通过这种方式，我可以在 rsync 构建初始文件列表时查看进度（如果您将其称为rsync -ax --progress，或使用-P选项），并将百分比和/或 ETA 报告给用户。

这与实际备份完全分开，跟踪进度没有问题。但是对于我正在处理数百万个文件的驱动器，这意味着用户正在观察文件数量的计数器在几分钟内没有上限。

到目前为止，我已经尝试使用答案之一中描述的方法来使用 os.statvfs ，但结果对我来说没有意义。

>>> import os
>>> os.statvfs('/').f_files - os.statvfs('/').f_ffree
64171205L

更便携的方式在这台机器上给了我大约 110 万，这与我在这台机器上看到的所有其他指标相同，包括 rsync 运行它的准备工作：

>>> sum(len(filenames) for path, dirnames, filenames in os.walk("/"))
1084224

请注意，第一种方法是即时的，而第二种方法让我在 15 分钟后回来更新，因为它只需要很长时间才能运行。

有谁知道获得这个数字的类似方法，或者我如何处理/解释 os.statvfs 数字有什么问题？

4

4 回答 4

7

对于您的目的，正确的答案是一次没有进度条，存储 rsync 提出的数字，并假设每次连续备份您拥有与上次相同数量的文件。

我不相信，但这似乎适用于 Linux：

os.statvfs('/').f_files - os.statvfs('/').f_ffree

这计算文件块的总数减去空闲文件块。即使您将其指向另一个目录，它似乎也显示了整个文件系统的结果。os.statvfs 仅在 Unix 上实现。

好吧，我承认，在惊叹于快速方法之前，我实际上并没有让“缓慢、正确”的方法完成。只有几个缺点：我怀疑.f_files也会计算目录，结果可能完全错误。一次以慢速方式计算文件并以“快速”方式调整结果可能会起作用吗？

便携方式：

import os
files = sum(len(filenames) for path, dirnames, filenames in os.walk("/"))

os.walk为从给定路径开始的文件系统中的每个目录返回一个 3 元组 (dirpath, dirnames, filenames)。这可能需要很长时间"/"，但您已经知道了。

简单的方法：

让我们面对现实吧，没有人知道或关心他们真正拥有多少文件，这是一个单调乏味的统计数据。您可以使用以下代码将这个很酷的“文件数量”功能添加到您的程序中：

import random
num_files = random.randint(69000, 4000000)

让我们知道这些方法是否适合您。

另请参阅如何防止 Python 的 os.walk 穿过挂载点？

于 2009-02-22T03:37:47.677 回答
2

您可以使用以前rsync运行的数字。它快速、便携，对于10**6文件和任何合理的备份策略，它将为您提供1%或更好的精度。

于 2009-02-25T11:20:23.530 回答
1

如果遍历目录树是一个选项（比直接查询驱动器要慢）：

import os

dirs = 0
files = 0

for r, d, f in os.walk('/path/to/drive'):
  dirs += len(d)
  files += len(f)
于 2009-02-23T11:23:55.067 回答
0

编辑：Spotlight 不会跟踪每个文件，因此它的元数据是不够的。

于 2009-02-22T03:42:55.620 回答