The differences came from different reasons: different ways of counting, different tools, compression and what looks like a bug.
The first difference in size you see seems to be a bug in the Finder. The file sizes shown by the Finder are somehow calculated in real time and cached in .DS_Store
files. For some reason, while duplicating a big application/folder, the Finder calculates its size during the copy process and caches the, then incomplete, size. It then shows that size as greyed in the Finder windows, grey meaning the Finder knows the content has changed since it's last size calculation but it hasn't recalculate it yet.
The only way I've found to make it recalculate correctly the size is by deleting the .DS_Store
file in the Application folder, then quitting the Finder (from the Activity Monitor for example) and relaunching it again (from the Dock Icon). If you don't delete the .DS_Store
file, it still stays out greyed. Maybe waiting some time (hours, days, reboot, ...) will make the Finder do it by itself.
After that, you should see that all sizes reported by the Finder are the same.
So yes, it looks like a Finder bug, at least in OSX Lion (tested with 10.7.4 here, Finder version 10.7.3). You can also see this thread which reports same kind of behavior.
Then, let's consider the du
tool. At first, I thought the difference we see could be explained by the difference between logical and physical sizes of items being copied. Logical size is the real size of the item, meaning every single bit of information it contains added up together. Physical size is the size of the item on the disk, where each information bit is written on a disk sector.
For example a file containing a single character would end up having a 1 byte logical size, but a 512 bytes or even 4096 bytes physical size when actually written to disk. The physical size is usually larger than the logical size (and depends on the actual sector/block size of the disk or the file system). This is explained into more details in this other thread. Logical size could be larger in the case of sparse files, but HFS+ doesn't seem to support such a feature.
du
shows only the physical size (and you can tell it what a BLOCKSIZE is). You can see that the size reported by du
is always bigger (or, exceptionally, the same) as the original. This is because of file system and disk space fragmentation. When you copy over a file (actually here a bunch of files, as an Application is a directory) new sectors are being allocated on the disk and, as fragmentation occurs, the number of blocks used is usually higher than that of the original item. Some people call that File Slack.
Now, back to the Finder. If you open up the get info window of the Applications you duplicated, you'll see that the Finder is actually reporting both the Logical and the Physical size of the item you selected. Which then makes sense. You'll even be able to compare the Physical size reported by the Finder and the one reported by du
if you do a bit of math.
Why doing some math? Because the Finder shows the file sizes in kB, MB or GB where du
reports them in kiB, MiB or GiB. Those are the IEC binary prefixes which should be used to calculate and display units of digital information.
But, actually, I'm not sure File Slack is involved here, there's something else. HFS+ volumes allow compression, done transparently, and Apple uses that for the original items installed by the OS. Then, when files are copied using standard tools, compression is not used anymore (as a default, to be backward compatible). If you want to keep compression on those files, you need to use the ditto
command instead of cp
or any Finder action. This is explained in this review.
Here is the output of copying iTunes.app using the different techniques. You'll see that ditto makes the Application exactly the same size, preserving compression, where cp
doesn't. And you can even remove the binary for the arch you don't need, then reducing the whole size):
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
Thanks to @DanPritts for his answer on my complementary post.
Best Answer
HFS+ compression!
The "Size" value represents the uncompressed size of the data in the file. The "on disk" value is how much storage is really needed for the compressed data. The Mac OS X Hints site provides background on how this compression is implemented, and provides a link to the helpful
hfsdebug
tool that can be used to get information on compressed files.