Mac OS X not reporting directory sizes correctly?

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.

It's a horrid flaw/bug in OS X. The easiest way to see it is to duplicate a large application bundle, then show the contents and delete a huge file from within. The space will not recover. The file is still huge. For example, if you have a 3.5GB application bundle, you show the contents, then remove 3GB from it, you should now have an application with the file size of 500MB. You will not. It will still be 3.5GB.

This is basically a guess, but I see two possibilities:

1. Some data has been deleted but not deallocated in the original, and this is not copied over. Yet it shows up in some disk usage searches, but not others (different parameters given to du or whatever OS X use internally).
2. Some data gets linked to the original location, and this affects perceived size in different tools.

If (1) you should probably get different results making a third copy and comparing the copies.

Firstly, you need to be aware that Mac .app files are in fact Directories, not compiled binaries like Windows .exe files. The Finder just hides this fact from you for folders called *.app.

e.g. (from Terminal)

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

I'm pretty sure what's happening is that Finder / Get Info is using some not-very-clever heuristic to calculate the size of the .app folder. This means it doesn't need to enumerate every single subfolder and file and add together all those sizes.

My guess is that the estimate on the copy is correct because OSX has recently had to inspect every file in it when you did the copy, whereas on the original, OSX may never have had to do so (e.g. with factory installs)