Mac OS X无法正确报告目录大小?


16

在Finder中,我注意到如果我复制一些.app文件(在Applications文件夹中),Finder将显示重复的.app文件与原始文件大小不同。我复制的所有.app文件都不会出现这种文件大小差异,但看起来.app文件越大,副本就越不会显示与原始文件相同的大小。这里有些例子:

GarageBand.app - 381.7 MB
GarageBand copy.app - 373.2 MB

iMovie.app - 695.3 MB
iMovie copy.app - 635.4 MB

Install Xcode.app - 1.81 GB
Install Xcode copy.app - 1.57 GB

现在我是Mac的新手,在我注意到这个文件大小差异问题之后,我发现.app文件实际上不是文件 - 它们实际上是目录,但是Finder将它们显示为文件。所以我想也许复制过程没有复制原始.app目录的所有内容,这解释了“文件大小”的差异。但后来我下载并安装了DeltaWalker,这是一个文件/文件夹差异工具,而DeltaWalker说重复的.app目录与原始.app目录完全相同。因此复制过程工作得很好,因此Finder报告文件大小似乎是一个问题。

我还使用“du”命令检查了Terminal中目录的大小,这也显示了原始目录和重复目录之间的大小差异:

du -k /Applications/GarageBand.app/
212868  /Applications/GarageBand.app/

du -k /Applications/GarageBand\ copy.app/
397880  /Applications/GarageBand copy.app/

du -k /Applications/iMovie.app/
629644  /Applications/iMovie.app/

du -k /Applications/iMovie\ copy.app/
700500  /Applications/iMovie copy.app/

du -k /Applications/Install\ Xcode.app/
1771864 /Applications/Install Xcode.app/

du -k /Applications/Install\ Xcode\ copy.app/
1772228 /Applications/Install Xcode copy.app/

此外,它不仅仅是.app目录。我复制了我的/ Developer / Library目录,这就是du所说的:

du -k /Developer/Library/
320784  /Developer/Library/

du -k /Developer/Library\ copy/
399868  /Developer/Library copy/

那么有谁可以解释为什么Mac OS X似乎没有正确报告目录大小?这是一个错误(很难相信这么简单的东西),还是我错过了什么(成为新的Mac用户)?

(我正在运行Mac OS X Lion 10.7.2)


更新以回应elofturtle:

最奇怪的是,Finder没有一致性。我刚刚制作了2个重复的GarageBand.app,然后制作了两个副本中的一个副本。Finder显示每个具有不同大小的副本:

GarageBand.app - 381.7 MB
GarageBand copy.app - 357.6 MB (duplicate of GarageBand.app)
GarageBand copy 2.app - 353.9 MB (duplicate of GarageBand.app)
GarageBand copy 3.app - 378.2 MB (duplicate of GarageBand copy 2.app)
GarageBand copy 4.app - 329.1 MB (duplicate of GarageBand copy 2.app)

另请注意,“GarageBand copy 3.app”大于“GarageBand copy 2.app”,而“GarageBand copy 4.app”小于“GarageBand copy 2.app”。那必须是Finder中的一个错误。

以下是关于所有这些内容的“du -k”:

212868  /Applications/GarageBand.app/
397880  /Applications/GarageBand copy.app/
397880  /Applications/GarageBand copy 2.app/
397880  /Applications/GarageBand copy 3.app/
397880  /Applications/GarageBand copy 4.app/

至少它说所有的副本都是相同的大小,但它们的大小与原始大小不同。


我有一个预感,这将归结为硬链接和符号链接,以及当您复制这些.app包时转换为单独的文件副本中的一个或另一个。顺便说一句,你是否在相同的卷(分区?)中复制它们。
Spiff

我的答案下面有什么遗漏吗?我的印象是,这是对你的问题的完整答案,但到目前为止你没有发表任何评论。你能告诉我吗?
Tonin

1
我为延迟道歉。在我对这个问题失去兴趣之后,你得到了答案。但你的答案非常棒 - 非常详细,它确实完全回答了我的问题。非常感谢,我必须记住,即使实际压缩了文件/文件夹,Finder也会显示未压缩的大小。
pacoverflow

重新标记这个,也许我应该标记它[copy]? - 但是以牺牲其他标签为代价?
ArneStenström2013年

Answers:


12

差异来自不同的原因:不同的计数方式,不同的工具,压缩和看起来像一个bug。

您看到的第一个大小差异似乎是Finder中的一个错误。Finder显示的文件大小以某种方式实时计算并缓存在.DS_Store文件中。出于某种原因,在复制大型应用程序/文件夹时,Finder会在复制过程中计算其大小并缓存大小不一致的大小。然后它显示在Finder窗口中灰色的大小,灰色意味着Finder知道内容已经更改,因为它是最后一次大小计算,但它还没有重新计算它

我发现正确重新计算大小的唯一方法是删除.DS_StoreApplication文件夹中的文件,然后退出Finder(例如,从Activity Monitor)并再次重新启动它(从Dock图标)。如果您不删除该.DS_Store文件,它仍然保持灰色。也许等待一段时间(几小时,几天,重新启动......)将使Finder自己完成。

之后,您应该看到Finder报告的所有尺寸都是相同的。

所以,是的,它看起来像一个Finder错误,至少在OSX Lion中(在这里用10.7.4测试,Finder版本10.7.3)。您还可以看到报告此类行为的此线程

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

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

du仅显示物理尺寸(您可以告诉它BLOCKSIZE是什么)。您可以看到报告的大小du始终比原始大小(或特殊地,相同)。这是因为文件系统和磁盘空间碎片。当您复制文件(实际上这里是一堆文件,因为Application是一个目录),磁盘上会分配新的扇区,并且当发生碎片时,使用的块数通常高于原始项的块数。有些人称之为File Slack

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

为什么要做一些数学?因为Finder以kB,MB或GB为单位显示文件大小,du以kiB,MiB或GiB 格式报告。这些是IEC二进制前缀,应该用于计算和显示数字信息单位。

但是,实际上,我不确定File Slack是否参与其中,还有其他的东西。 HFS +卷允许压缩,透明地完成,Apple将其用于操作系统安装的原始项目。然后,当使用标准工具复制文件时,不再使用压缩(默认情况下,向后兼容)。如果要对这些文件保持压缩,则需要使用ditto命令而不是cp任何Finder操作。本次审查对此进行了解释

以下是使用不同技术复制iTunes.app的输出。你会看到ditto使应用程序的大小完全相同,保留压缩,而cp不是。你甚至可以删除你不需要的拱形二进制文件,然后减小整个大小):

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 对我补充帖子的回答。


不是相反吗?Finder显示实际的SI前缀。
Daniel Beck

稀疏文件(不是 OS X的稀疏捆绑/映像)是否具有比物理文件大小更大的逻辑?
丹尼尔贝克

是的,你是对的,Finder显示SI前缀和duIEC,我会更正我的帖子。
Tonin

@DanielBeck稀疏文件,理论上可能是,是的,但是OSX应用程序将具有什么样的文件作为稀疏文件? 根据维基百科,HFS +不支持稀疏文件。
Tonin

该段看起来像它通常适用(取决于磁盘或文件系统的实际扇区/块大小),所以这就是我想提到的原因。
丹尼尔贝克

1

这是OS X中一个可怕的缺陷/错误。最简单的方法是复制一个大型应用程序包,然后显示内容并从内部删除一个巨大的文件。空间不会恢复。该文件仍然很庞大。例如,如果你有一个3.5GB的应用程序包,你显示内容,然后从中删除3GB,你现在应该有一个文件大小为500MB的应用程序。你不会。它仍然是3.5GB。


要重新计算尺寸,请在文件夹视图选项中选择计算所有尺寸。请参阅apple.stackexchange.com/a/227173/156178
asmaier

0

这基本上是猜测,但我看到两种可能性:

  1. 某些数据已被删除但未在原始数据中取消分配,并且不会复制。然而,它出现在一些磁盘使用搜索中,而不是其他(为du或OS X内部使用的不同参数)。
  2. 某些数据会链接到原始位置,这会影响不同工具中的感知大小。

如果(1)您应该得到不同的结果,制作第三份副本并比较副本。


抱歉,无法在评论中查看多行代码块,因此我会尝试编辑原始帖子。
pacoverflow

我不会期望重复项比原来的更大: - /它似乎值得一个错误报告,但我打赌有机会获得有关Finder内部工作的任何反馈,导致这个很小。不过,希望他们能看看它。
elofturtle

0

首先,您需要知道Mac .app文件实际上是目录,而不是像Windows .exe文件那样编译的二进制文件。Finder只是隐藏了这个名为* .app的文件夹的事实。

例如(来自终端)

# cd /Applications/Calculator.app
# ls
Contents/

我很确定发生的事情是Finder / Get Info正在使用一些非常聪明的启发式方法来计算.app文件夹的大小。这意味着它不需要枚举每个子文件夹和文件,并将所有这些大小加在一起。

我的猜测是副本上的估计是正确的,因为OSX最近不得不在复制时检查其中的每个文件,而在原始版本上,OSX可能永远不必这样做(例如,使用工厂安装)


-1

一旦我在SSD上安装Yosemite后将其移动到内部硬盘上,我的主目录就出现了这个问题。当使用“获取信息”时,它报告的大小不正确只有8GB,尽管它在Finder的状态栏中显示了正确的240GB大小。我通过单击“用户”文件夹上的“获取信息”来修复它,然后正确计算并修复了主目录报告的错误大小。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.