Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

share|improve this question
    
I have a hunch this is going to come down to hardlinks and symlinks, and one or the other of those getting converted into separate file copies when you duplicate those .app bundles. By the way, are you duplicating them within the same volume (partition?). –  Spiff May 10 '12 at 7:12
    
Is there anything missing to my answer below? I have the impression that it's a full answer to your question, but there was no comment from you so far. Can you please let me know? –  Tonin Dec 3 '12 at 16:14
1  
I apologize for the delay. Your answer came in after I had lost interest in the question. But your answer is superb - very detailed and it indeed fully answers my question. Thank you very much, and I'll have to remember that the Finder displays uncompressed sizes even if the file/folder is actually compressed. –  pacoverflow Dec 5 '12 at 8:23
    
Re-tagging this, maybe I should have tagged it [copy]? – But at the expense of which other tag? –  Arne Stenström Mar 27 '13 at 12:43

4 Answers 4

up vote 6 down vote accepted

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.

share|improve this answer
    
Isn't it the other way around? Finder shows actual SI prefixes. –  Daniel Beck Aug 1 '12 at 17:44
    
Wouldn't sparse files (not sparse bundles/images of OS X) have a greater logical than physical file size? –  Daniel Beck Aug 1 '12 at 17:46
    
Yes, you're right, Finder shows SI prefixes and du IEC, I'll correct my post. –  Tonin Aug 1 '12 at 17:51
    
@DanielBeck Sparse files, in theory it could be, yes, but what kind of files an OSX application would have as sparse files? According to wikipedia, sparse files are not supported on HFS+. –  Tonin Aug 1 '12 at 17:55
    
That paragraph reads like it's generally applicable (depends on the actual sector/block size of the disk or the file system), so that's why I wanted to mention that. –  Daniel Beck Aug 1 '12 at 17:59

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.

share|improve this answer
    
Sorry, can't get multiline code blocks to look right in a comment, so I'll try editing my original post. –  pacoverflow Jan 29 '12 at 7:10
    
I wouldn't have expected the duplicates to be larger than the original :-/ It seems worthy of a bug report, but I wager the chances of getting any feedback on the inner workings of Finder causing this are slim. Hopefully they'll take a look at it, though. –  elofturtle Jan 29 '12 at 19:19

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)

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.