2
Case in point: Apple's TextEdit at /Applications/TextEdit.app
If you calculate the physical size with echo "$(/usr/bin/du -k -d 0 /Applications/TextEdit.app | /usr/bin/awk '{print $1}') * 1024" | /usr/bin/bc -l
you'll get (in my case on 10.11.6) a size of 4538368 bytes.
However, if you open the Info window in Finder, it'll tell you that the physical size is way bigger: 8.6 MB on disk, almost double the size.
It's clear why: Apple used HFS compression on TextEdit. Running the third-party tool afsctool (which you can install with Homebrew) produces this result:
/usr/local/bin/afsctool /Applications/TextEdit.app
/Applications/TextEdit.app:
Number of HFS+ compressed files: 693
Now, macOS obviously seems to know the uncompressed physical size, as evidenced by the size-on-disk value in the Finder's Info window.
My question is, if there is a command-line read-only way to get that info, i.e. a way to show:
(a) the uncompressed physical size (disk use) of a file that is HFS-compressed, i.e. a file for which /usr/bin/stat -f %f
returns "32" (even though it's "524320" for some reason in TextEdit), and
(b) the uncompressed total physical size (disk use) of a directory or bundle that contains HFS compressed files.
Note: only macOS native commands should be used to calculate the size, while not using Spotlight-dependent data, e.g. from the mdls
command, which is buggy and sometimes returns (null)
for the kMDItemPhysicalSize
key, aside from the fact that some users have disabled Spotlight altogether.