Mac OS X 没有正确报告目录大小？

Question 1

差异来自不同的原因：不同的计数方式、不同的工具、压缩以及看起来像是错误的东西。

这一阶差分你看到的尺寸似乎是一个Finder 中的错误。Finder 显示的文件大小以某种方式实时计算并缓存在.DS_Store文件中。出于某种原因，在复制大型应用程序/文件夹时，Finder 会在复制过程中计算其大小并缓存当时不完整的大小。然后它在 Finder 窗口中将该大小显示为灰色，灰色表示Finder 知道内容自上次计算大小以来已经发生了变化，但它还没有重新计算。

我发现让它重新正确计算大小的唯一方法是删除.DS_Store应用程序文件夹中的文件，然后退出 Finder（例如从活动监视器中）并重新启动它（从 Dock 图标中）。如果你不删除该.DS_Store文件，它仍然会保持灰色。也许等待一些时间（小时，天，重启，...）将使 Finder 自行执行此操作。

此后，您应该会看到 Finder 报告的所有尺寸都是相同的。

所以是的，这看起来像是 Finder 的一个错误，至少在 OSX Lion 中是这样的（这里测试的是 10.7.4，Finder 版本是 10.7.3）。您还可以看到此主题报告了相同类型的行为。

然后，让我们考虑一下这个du工具。起初，我认为我们看到的差异可以通过复制项目的逻辑大小和物理大小之间的差异来解释。逻辑大小是真实的项目的大小，即其中包含的每一位信息的总和。物理大小是磁盘上项目的大小，其中每个信息位都写在磁盘扇区上。

例如，一个包含单个字符的文件最终将具有 1 字节的逻辑大小，但实际写入磁盘时物理大小为 512 字节甚至 4096 字节。物理大小通常大于逻辑大小（取决于磁盘或文件系统的实际扇区/块大小）。这是在另一个线程中更详细地解释. 逻辑大小可能更大的情况下稀疏文件，但HFS+好像不支持这样的功能。

du只显示物理大小（你可以告诉它 BLOCKSIZE 是什么）。你可以看到报告的大小du总是比原始大小大（或者，在例外情况下，相同）。这是因为文件系统和磁盘空间碎片。当你复制一个文件（实际上这里是一堆文件，因为应用程序是一个目录）时，磁盘上会分配新的扇区，并且，随着碎片化发生，使用的方块数量通常高于原始物品的数量。有些人称之为文件松弛。

现在，回到 Finder。如果您打开获取信息在复制的应用程序窗口中，您会看到 Finder 实际上报告了所选项目的逻辑大小和物理大小。这很有意义。du如果您进行一些数学运算，您甚至可以比较 Finder 报告的物理大小和报告的物理大小。

为什么要做数学题？因为 Finder 显示文件大小的单位是 kB、MB 或 GB，而du报告的单位是 kiB、MiB 或 GiB。这些是IEC 二进制前缀用于计算和显示数字信息的单位。

但实际上，我不确定这里是否涉及 File Slack，还有其他东西。 HFS+ 卷允许压缩，透明地完成，Apple 将其用于操作系统安装的原始项目。然后，当使用标准工具复制文件时，不再使用压缩（默认情况下，为了向后兼容）。如果您想保留这些文件的压缩，您需要使用命令ditto而不是cp或任何 Finder 操作。这是在这篇评论中解释。

以下是使用不同技术复制 iTunes.app 的输出。您会看到 ditto 使应用程序的大小完全相同，保留了压缩，而cp没有。您甚至可以删除不需要的 arch 的二进制文件，然后减小整个大小）：

antoine@amarante:/Applications$ du -ms iTunes.app/
281 iTunes.app/
antoine@amarante:/Applications$ cp -a iTunes.app/ iTunes-copy.app/
antoine@amarante:/Applications$ ditto iTunes.app/ iTunes-ditto.app
antoine@amarante:/Applications$ ditto --arch x86_64 iTunes.app/ iTunes-64.app
antoine@amarante:/Applications$ du -ms iTunes*
236 iTunes-64.app
289 iTunes-copy.app
281 iTunes-ditto.app
281 iTunes.app

感谢@DanPritts 的回答在我的补充帖子上。

Answer