Mac OS X not reporting directory sizes correctly?
In Finder, I've noticed that if I duplicate some .app files (in the Applications folder), Finder will show that the duplicate .app file is not the same size as the original. This file size discrepancy does not happen for all .app files that I duplicate, but it seems like the larger the .app file, the more likely that the duplicate will not show the same size as the original. Here are some examples:
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
Now I am new to Macs, and after I noticed this file size discrepancy problem, I discovered that .app files are actually not files - they are really directories, but Finder displays them as if they are files. So I thought maybe the duplication process did not copy all of the contents of the original .app directory and that explained the difference in "file size". But then I downloaded and installed DeltaWalker, which is a file/folder diff tool, and DeltaWalker said that the duplicate .app directories were exactly the same as the original .app directories. So the duplication process worked perfectly, and it therefore seems to be a problem with Finder reporting file sizes.
I also checked the sizes of the directories in Terminal, using the "du" command, and that too shows discrepancies in sizes between the original and duplicate directories:
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/
Also, it's not just .app directories. I duplicated my /Developer/Library directory, and here's what du said:
du -k /Developer/Library/
320784 /Developer/Library/
du -k /Developer/Library\ copy/
399868 /Developer/Library copy/
So can anyone explain why Mac OS X doesn't seem to report directory sizes correctly? Is it a bug (hard to believe for something so simple), or am I missing something (being a new Mac user)?
(I'm running Mac OS X Lion 10.7.2)
UPDATE in response to elofturtle:
What is most strange about this is that Finder has no consistency. I just made 2 duplicates of the GarageBand.app, and then made 2 duplicates of one of the duplicates. Finder displays every single duplicate with a different size:
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)
Also note that "GarageBand copy 3.app" is larger than "GarageBand copy 2.app", while "GarageBand copy 4.app" is smaller than "GarageBand copy 2.app". That has to be a bug in Finder.
Here's what "du -k" says about all of them:
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/
At least it says all the duplicates are the same size, but they're not the same size as the original.
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.