Other than the name and location of a file, the most obviously important information about it is its size. Although we may have learned to be sceptical of overall disk usage as quoted in the Storage tab of About This Mac…, and High Sierra often gives several different figures for free space available on volumes and disks, we trust what Finder’s Get Info reports for a file’s size, don’t we?

Perhaps we shouldn’t.

Here’s a little experiment to demonstrate that macOS – ever since its first beta release nearly eighteen years ago – doesn’t report file sizes accurately. In extreme cases, not even within 100%.

Take a small text file, in my example just 391 bytes of data. Open it in my extended attribute editor xattred, and paste in some hefty extended attributes copied from other files. Resource forks (com.apple.ResourceFork) such as image thumbnails or previews are usually pretty good. In my case, as well as a range of smaller extended attributes, I added a large chunk of keywords, and disguised an image preview as a ‘where from’.

Given that these come to a total of 90894 bytes in addition to the 391 bytes of data, any file size claimed to be less than 90 KB is clearly wrong.

Yet the Finder’s Get Info dialog still pretends that there are only 391 bytes, and that the file fits into a single 4 KB storage unit.

Try Terminal, using the ls command, and you’ll see the same:
-rw-r--r--@ 1 hoakley staff - 391 26 Oct 19:47 0icloudtest01.txt

It’s only when you add the @ command option to list the extended attributes that you can see how big that file really is:
-rw-r--r--@ 1 hoakley staff - 391 26 Oct 19:47 0icloudtest01.txt
com.apple.TextEncoding 836
com.apple.metadata:_kMDItemUserTags 50
com.apple.metadata:kMDItemCopyright 162
com.apple.metadata:kMDItemCreator 55
com.apple.metadata:kMDItemKeywords 9732
com.apple.metadata:kMDItemWhereFroms 80059
and then you’ll need to add the total up yourself.

Of course in HFS+ and APFS, those extended attributes aren’t stored in the normal file data on disk, but in the volume metadata. But they still occupy space, and when you come to copy that file anywhere, its extended attributes go with it. If the destination happens to be a USB memory stick in ExFAT format, Finder’s Get Info still ignores the extended attributes.

When you list the contents in Terminal, though, you’ll be shown the hidden file containing the extended attributes:
-rwxrwxrwx 1 hoakley staff hidden 94208 29 Jan 12:29 ._0icloudtest01.txt
-rwxrwxrwx@ 1 hoakley staff - 391 26 Oct 19:47 0icloudtest01.txt
Because ._0icloudtest01.txt is a single file containing all those extended attributes, it has a little additional overhead.

These days, with many files not using extended attributes and most of them relatively small, the difference between the file sizes given by macOS and the real figure including extended attributes is unlikely to be as great as in my pathological example.

But way back in the days of Classic Mac OS, this information was readily available in a bundled free tool, ResEdit, which offered a Get Info dialog quoting separate sizes for the data and resource forks of a file.

And over millions of files, even small extended attributes add up. Perhaps it’s time for macOS to get a little nearer telling the truth?