What is the explanation for the difference:

$ ls -l /Applications/Safari.app/Contents/Info.plist
-rw-r--r--  1 root  wheel  15730 11 jui 15:02 /Applications/Safari.app/Contents/Info.plist

$ du -sh /Applications/Safari.app/Contents/Info.plist
0B     /Applications/Safari.app/Contents/Info.plist

Once the file is copied in my home folder, ls and du report the same number.

$ cp /Applications/Safari.app/Contents/Info.plist .
$ du -sh Info.plist; ls -l Info.plist
16K Info.plist
-rw-r--r--  1 ant  staff  15730 17 oct 16:53 Info.plist

Both directories are on this partition ( / )

diskutil  info /
Device Identifier:        disk0s2
Device Node:              /dev/disk0s2
Part of Whole:            disk0
Device / Media Name:      ml2013

Volume Name:              OSX.10.8
Escaped with Unicode:     OSX.10.8

Mounted:                  Yes
Mount Point:              /
Escaped with Unicode:     /

File System Personality:  Journaled HFS+
Type (Bundle):            hfs
Name (User Visible):      Mac OS Extended (Journaled)
Journal:                  Journal size 40960 KB at offset 0xc83000
Owners:                   Enabled

Here is the output of stat:

$ stat  Info.plist
16777218 8780020 -rw-r--r-- 1 root wheel 0 15730 "Oct 17 17:47:12 2013" \ 
"Jun 11 15:02:17 2013" "Jun 11 15:02:17 2013" "Apr 27 11:49:34 2013"\ 
4096 0 0x20 Info.plist
  • Once the file is copied where?
    – terdon
    Oct 17, 2013 at 14:50
  • @terdon See my edit.
    – alecail
    Oct 17, 2013 at 14:55
  • Are both directories on hfs+ filesystems?
    – terdon
    Oct 17, 2013 at 14:57

3 Answers 3


I may have found something:

The ls command on OS X has this switch:

  -O      Include the file flags in a long (-l) output.

The result is:

$ ls -O Info.plist
-rw-r--r--  1 root  wheel  compressed 15730 11 jui 15:02 Info.plist

I just checked (experimentally) that du always reports 0 for HFS+ compressed files.

Copying compressed files uncompress them; so logically du reports the correct file on a copied, uncompressed file.

Here is an explanation for the behaviour of du:

HFS+ File Compression

In Mac OS X 10.6, Apple introduced file compression in HFS+. Compression is most often used for files installed as part of Mac OS X; user files are typically not compressed (but certainly can be!). Reading and writing compressed files is transparent as far as Apple's file system APIs.

Compressed files have an empty data fork. This means that forensic tools not aware of HFS+ file compression (including TSK before 4.0.0) will not see any data associated with a compressed file!

There is also a discussion on this subject in Mac OS X and iOS Internals: To the Apple's Core by Jonathan Levin , in chapter 16: To B(-Tree) or not to be - The HFS+ file systems.

Also afsctool may help see which files are compressed in a folder.

$ afsctool -v /Applications/Safari.app/
Number of HFS+ compressed files: 1538
Total number of files: 2247
Total number of folders: 144
Total number of items (number of files + number of folders): 2391
Folder size (uncompressed; reported size by Mac OS 10.6+ Finder): 29950329 bytes / 34.7 MB (megabytes) / 33.1 MiB (mebibytes)
Folder size (compressed - decmpfs xattr; reported size by Mac OS 10.0-10.5 Finder): 21287197 bytes / 23.8 MB (megabytes) / 22.7 MiB (mebibytes)
Folder size (compressed): 22694835 bytes / 25.2 MB (megabytes) / 24 MiB (mebibytes)
Compression savings: 24.2%
Approximate total folder size (files + file overhead + folder overhead): 26353338 bytes / 26.4 MB (megabytes) / 25.1 MiB (mebibytes)

When using du and you're comparing the results from 2 different runs against file systems you need to make sure to use the switch --apparent-size.


Here's a CIFS mounted share.

$ du -sh somedir
50M somedir

$ du -sh --apparent-size somedir
45M somedir

excerpt from du man page

          print  apparent  sizes,  rather than disk usage; although the apparent 
          size is usually smaller, it may be larger due to holes in (‘sparse’)
          files, internal fragmentation, indirect blocks, and the like

So what's up?

This confuses a lot of people but remember that when files are stored to a disk they consume blocks of space even if they're only using a portion of those blocks. When you run du without the --apparent-size you're getting the size based on the amount of disk's block space used, not the actual space consumed by the file(s).

What about the 0B size?

0B /Applications/Safari.app/Contents/Info.plist

This is most likely a link. Doing this command will show if this is the case.

$ ls -l /Applications/Safari.app/Contents | grep Info.plist
  • man page from which OS ?
    – alecail
    Oct 17, 2013 at 15:18
  • @AntoineLecaille from Linux, unfortunately, BSD du (which is what OSX uses) doesn't have that option.
    – terdon
    Oct 17, 2013 at 15:20
  • @AntoineLecaille - look for a switch to your du that specifies something regarding "apparent" or "size". You can always install the GNU version of du too.
    – slm
    Oct 17, 2013 at 15:24
  • 1
    @terdon - one reason would be that if the files were consuming portions of multiple blocks. du would report the fragmented directory as larger than the copy. When you copy the files from one location on disk to another the system has the opportunity to do a "defrag" and consolidate the files data into fewer blocks.
    – slm
    Oct 17, 2013 at 15:33
  • 1
    @AntoineLecaille - the other thing I've seen with OSX is those .plist files are just links. Can you confirm if this is the actual file or a link to some other file? That would explain the 0 size.
    – slm
    Oct 17, 2013 at 15:37

My answer is inline with others, but I can't comment yet so I get to start new:

Most files in /Applications are compressed and when you copy it that is lost. When compression is used in HFS+ the files data is stored in the Resource Fork OR an extended attribute if it's small enough ( less than 4k). If it's in a resource fork du (at least on Yosemite) will show it's actual disk usage in blocks. If it's entirely in the attribute it will show 0.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .