Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

There is a behavior I cannot explain in OSX Lion (might be on other versions too).

When I copy or duplicate some applications, for example iTunes, that contain some dynamic libraries, the physical size of those libraries changes (the size grows). This can be because of disk fragmentation. But it is not only that, because what is surprising is that the original physical size is smaller than the logical size (where usually the physical size is always bigger than the logical one, except when there is compression involved).

To illustrate my case:

antoine@amarante:/Applications$ ls -ls 
384 -rwxrwxr-x+ 1 root  admin  558704  8 jul  2011

ls considers a block size of 512 bytes, 384 blocks make 196608 bytes compared to the 558704 bytes reported logical size. Or, as shown in a get info window from the Finder:

558.704 octets (197 Ko sur disque)

This is also shown after some copy operations where I copied over the whole iTunes application. The first iTunes copie is a duplicate done through the Finder and iTunes-cp is a copy done with the CLI cp -a command.

antoine@amarante:/Applications$ ls -ls iTunes*.app/Contents/MacOS/libgnsdk_dsp.1.8.2.dylib 
11632 -rwxr-xr-x+ 1 antoine  admin  5955104  8 jul  2011 iTunes
11632 -rwxrwxr-x+ 1 antoine  admin  5955104  8 jul  2011
 3944 -rwxrwxr-x+ 2 root     admin  5955104  8 jul  2011

We see that the copied files have a physical size larger (11632*512 = 5955584 bytes) than the logical size (5955104), except for the original file which is a lot smaller. When I copy the single .dylib file on its own, the behavior is the same. This happens for a few dynamic library files, not for all.

How can the original library file be smaller than the copies? Is there some compression involved? Or are my original files corrupted in some way? How can I check that?

share|improve this question
Now when we know the size discrepancy is because of file system compression, I guess there's nothing specific about .dylib files regarding that, other than them being common examples of compressed files in the system. – Arne Stenström Mar 27 '13 at 12:38
up vote 3 down vote accepted

There is in fact compression in HFS+ on the mac on 10.6 and later. It's transparent, and can be difficult to even detect with standard OS tools.

And, it isn't always done. For backward compatibility the default is not to compress, but they do compress the OS when it's installed. has many gory details. lists how various command line tools view the sizes of compressed files.

Tool list, in case of link breakage:



stat -f %f - reports "user flags" on files - one of the flags means compression. I get "32" on a compressed file and "0" on an uncompressed file. Probably the 32 maps to a bit field.

ditto - has support for writing compressed files

share|improve this answer
Impressive. Thanks for your answer, I really learned something today! Using the ditto command will copy and preserve the compression, resulting in the same size. – Tonin Aug 2 '12 at 18:32
This discussion caused two rocks to click together in my head. Smallish SSD has been filling up lately... I found this: which will report on hfs compression, and will also compress files in place. sudo afsctool -ckv /Applications and I have 4 gigs back. – Dan Pritts Aug 7 '12 at 3:33

Your Answer


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.