文件夹大小不仅仅是所有文件的大小总和

有一天，上头来了一个活儿：我需要程序计算一个文件夹的大小。

有朋友可能会觉着，这事儿忒简单，只需要将这个文件夹里的所有文件的大小累加起来不就是文件夹的大小了。

如果它只是这样简单就好了。

有很多事情使计算文件夹的大小变得困难，其中一些甚至会令人怀疑”文件夹大小”这个概念是否真正存在。下面我们来看看。

重解析点(Reparse points)

关于重解析点，我们上次提到过这个。 在计算文件夹大小时，是否要递归处理重解析点？这取决于你计算文件夹大小的原因。 如果计算文件夹大小，是为了向用户显示删除文件夹后将会释放多少磁盘空间，那么是否这样做，取决于将如何删除重解析点。

如果计算大小是为了准备进行复制这个文件夹，那么你可能会这样做。 或者你可能不这样做——是否应该仅仅复制重解析点？ 如果用户没有创建重解析点的权限怎么办？ 或者如果目标位置不支持重解析点？ 或者如果用户创建副本是因为他们正在制作备份？

硬链接(Hard links)

硬链接是同一文件的多个文件夹条目。如果你在计算一个目录的大小并且你发现了一个硬链接，你会计算文件的完整大小吗？或者你是说硬链接的每个条目都承载着文件”权重”的一小部分？ (所以如果一个文件有两个硬链接，那么每个条目都占文件大小的一半。)

在硬链接之间划分文件的“权重”可以避免重复计算（或更高），以便在找到所有硬链接时，正确计算文件的总大小。它代表了一个概念，即所有指向文件的硬链接“分担”文件消耗的资源的成本。但是如果你没有找到所有的硬链接怎么办？文件大小被低估是正确的吗？

如果你正在复制一个文件并且你发现它有多个硬链接，你会怎么做？复制操作是否会破坏了副本中的链接？你会尝试重建它们吗？如果目的地不支持硬链接怎么办？

压缩文件(Compressed files)

我说的是文件系统压缩，而不是像ZIP这样的外部压缩算法。

将目录中文件的大小相加时，是逻辑大小还是物理大小相加？ 如果你正在计算准备复制的大小，那么你 可能需要逻辑大小，但如果是计算通过删除它可以释放多少磁盘空间，那么你可能需要物理大小。

但是，如果你正在计算复制并且复制目标支持压缩，那么到底要使用物理大小吗？ 现在假设源压缩算法和目标压缩算法具有可比性。

稀疏文件(Sparse files)

稀疏文件与压缩文件有同样的问题。 你想累加的是逻辑大小或物理大小？

簇舍入(Cluster rounding)

即使对于未压缩的非稀疏文件，你也可能需要考虑磁盘块的大小。 包含大量小文件的目录需要的磁盘空间比文件大小的总和还要多。 你想在计算中反映这一点吗？ 如果遍历了重解析点，则簇大小也可能发生了变化。

备用数据流(Alternate data streams)

备用数据流是文件可以占用磁盘空间的另一个地方，该空间并没有反映在其假定的“大小”中。

记录开销(Bookkeeping overhead)

总是存在与文件存储相关的记录数据。 除了文件夹条目（或多个文件夹）之外，还需要为安全信息以及跟踪文件内容所在位置的信息分配空间。 对于高度碎片化的文件，此信息可能相当广泛。 你想把它记入目录的大小吗？ 如果是这样，怎么做？

以上所有问题都没有单一的答案。 你必须考虑每一个因素，将其应用到你的情况，然后决定你想走哪条路。

（而且复制树形文件夹的结构更可怕。你用 ACL 做什么？你也想复制它们吗？你保留创建日期吗？这完全取决于你为什么要复制它。）

总结

希望猿友看完此文后能有所启发：文件夹里，除了普通的文件，还有各种各样，稀奇古怪的东西。

诸位，请提防提防！

最后

Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一，里面有很多关于Windows的小知识，对于广大Windows平台开发者来说，确实十分有帮助。

本文来自：《Computing the size of a directory is more than just adding file sizes》