相关疑难解决方法(0)

只是我遇到了一些事情，想不出合适的解释。如果我在我的 PC 上创建一个空的 *.txt 文件，然后查看它的大小，它会显示 0。但这怎么可能呢？我的意思是即使文件本身是空的，它仍然必须有一些大小，只是为了存储它自己的名字。这怎么解释？（非操作系统特定）

我有一个 xml 文件，windows explorer 说磁盘上有 8.00KB，大小为 25.5 KB。

这怎么可能？

我认为磁盘上的大小在许多情况下大于实际大小（因为块大小）？

由于文件系统分配等原因，我希望 Windows 资源管理器中的“大小”和“磁盘大小”之间存在一些差异。

下面是 Windows 2012 R2 文件服务器上的示例文件的屏幕截图，该文件的“大小”为 81.4 MB，但“磁盘大小”为 0 字节。是什么赋予了？

我有其他文件也在做同样的事情，但还有一组文件和文件夹按预期运行，显示磁盘上的大小相对接近实际文件大小。

该卷是一个基本磁盘，格式化为 NTFS 和默认的 4K 分配单元。没有为卷上的任何文件或文件夹设置压缩。（对于那些更偏执的人，我进行了恶意软件扫描，并确认没有与相关文件关联的 ADS 流）。

运行 Windows 资源管理器的用户帐户是域管理员，文件所有者也是域管理员。

谢谢阅读！

我要么对 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 簇磁盘上的两个簇中？肯定文件夹在某处占用了一些分配空间？

这是一个“问题”的很多问题，但我希望有人可以向我解释如何占用空间，包括文件名、文件夹和集群。