我要么对 Windows 如何计算Size on disk文件夹属性中的值感到困惑，要么它是不正确的。
我的驱动器上的簇大小为 4096 字节。
我创建了一个名为的文件夹size-on-disk-test，其中有 64 个直接子文件夹和 362,496 个文件。每个文件都是一个 3 字节大小的文本文件，仅包含文本：aaa。
鉴于每个文件理论上应该占用 4096 字节的单个簇，因此我应该期望看到磁盘上的文件大小为：
number-of-files * cluster-size→ 362,496 * 4096 = 1,484,783,616（1.4GB）。
而是这样的0：：
正如预期的那样Size，正好是 3 个字节乘以文件数量。
然后，我记下了磁盘根级别的可用空间并复制了该文件夹（这不是安装了任何活动或程序的驱动器，因此在测试期间它不应受到磁盘上其他缓存等的影响）。
根据复制文件夹后在根级别的检查（即单击“我的驱动器上的属性This PC”），我的可用空间减少了 589,352,960 字节。
那么到底发生了什么？为什么 Windows 报告磁盘大小为 0 字节？为什么我的计算与实际情况相差甚远？
此外，文件名的长度重要吗？在精确计算时不应该考虑到这一点吗？也许文件名长度将 4095 字节文件放入 4096 簇磁盘上的两个簇中？文件夹肯定会在某处占用一些分配空间？
对于一个“问题”来说，有这么多疑问，但我希望有人可以向我解释一下空间是如何占用的，包括文件名、文件夹和集群。
答案1
磁盘大小值最多只是一个近似值，在处理像 NTFS 这样的复杂文件系统时尤其如此。有许多因素使这一过程比乍一看要复杂得多。以下只是其中几个因素：
- 重新解析点
- 压缩文件
- 硬链接
- 稀疏文件
- 备用数据流
- 文件和文件夹开销
小文件可能完全适合 MFT，并且根本不会分配任何数据簇。具体大小取决于文件 MFT 条目中有多少可用空间。这取决于文件名的长度、安全信息所需的空间等等。
处理这些因素的最佳方法取决于你想如何使用这些信息。至于哪种方法最好，并没有明确的答案，因此必须做出许多随意的决定。
磁盘上的值仅作为参考。在某些情况下，例如对于大量非常小的文件，它甚至无法接近。只有指定所有参数才有可能实现真正的准确性，即使是专家也会发现这非常令人困惑。
请参阅此文章以了解更多信息： https://blogs.msdn.microsoft.com/oldnewthing/20041228-00/?p=36863/
答案2
文件夹肯定会占用一些分配空间吗？
是的，显然每个文件和文件夹的信息都必须存储在某个地方。在 NTFS 中，它位于骨髓纤维化. 这些被称为元数据和不计入文件大小。然而，在 NTFS 中，非常小的文件也可以直接存储在 MFT 条目中，不会占用任何额外空间。这些被称为常驻文件
您的文件仅3 个字节所以几乎可以肯定的是它们都适合 MFT，因此磁盘大小将为 0
此外，文件名的长度重要吗？在精确计算时不应该考虑到这一点吗？也许文件名长度将 4095 字节文件放入 4096 簇磁盘上的两个簇中？
事实上，文件名长度和其他元数据一样重要。例如具有多个流、复杂权限或多个硬链接的文件为常驻内容留出的空间会更少。MFT 中可存储的文件大小取决于条目中存储的内容。MFT 中用于元数据的数据越多，文件剩余的数据就越少。
小于约 900 字节的文件存储在 MFT 的目录条目内
https://en.wikipedia.org/wiki/NTFS#File_compression
图“带有驻留记录的 MFT 条目”显示了小文件或文件夹的 MFT 记录的内容。小文件和文件夹（通常为 900 字节或更小）完全包含在文件的 MFT 记录中。
但是如上所述，您的文件非常小，文件名、权限等占用的空间可以忽略不计，为所有文件留下足够的空间。此外，压缩文件和稀疏文件磁盘上的大小也会小于大小，因为实际存储在磁盘上的数据较少
进一步阅读