I would like to compute how much "true" APFS disk space is used by a folder. This folder has many APFS "cloned" versions of the same files. A "true" count of the disk space used would only count each of these clones once.

One thought I've had is to do this:

  1. Go through each file in the folder, recursively.
  2. Somehow determine, for each file, which physical location on the drive that file maps to.
  3. Build an array of these locations for all files; prune duplicates when they appear (which would be clones).
  4. Get the total computed size.

I am curious if one could use this kind of method to get the true size of the folder. I'm also curious if there are any existing utilities to do this, or if not, how I could implement this on my own. Perhaps using fcntl and F_LOG2PHYS, from this answer?

  • What if files in the folder share blocks with files outside the folder? Commented Jul 23, 2023 at 18:42
  • I want it to just report the total disk usage from that folder. So if you call it on some folder which has two subfolders, and the two subfolders share some files that are clones, the disk usages for the two folders won't sum to the disk usage of the folder above. Commented Jul 23, 2023 at 19:21

1 Answer 1


Yes, that method would be a starting point in getting the "true size" of the folder.

In practice, you would need to start with defining what you think is the "true size" of a folder, as that could very much vary from person to person.

For example: If files are compressed in the file system (i.e. not using an user space compression tool such as gzip or xz), would you regard the compressed or uncompressed size as the "true size"?

For example: If files contains "holes" (so called 'sparse files'), would you consider the size of the holes as part of the "true size" or not?

For example: If the file data (i.e. payload) does not match completely with the block size, would you consider the payload size the "true size" or would you round it up to a multiple of the block size?

And the list can probably go on with personal preferences of "true sizing".

  • Well, the goal of this is just to evaluate the number of bytes that some directory really takes up on the disk, not just evaluate the "true size" in some philosophical sense. The question is: if I delete this folder, and no clones of anything in it exist elsewhere on disk, how much space is freed? So the compressed size would be the thing I'd want, and etc. Commented Jul 24, 2023 at 3:19
  • 1
    I'm not talking philosophy - I'm just saying that the "practical definition" of true size varies from person to person and circumstance to circumstance. Perhaps you want the calculated size of the folder that you're removing to match the amount the free space counter in Finder grows by? Or some other metric that is relevant to you. Find that out first, then you can design a disk space calculation tool that will work that number out for you.
    – jksoegaard
    Commented Jul 24, 2023 at 7:24

You must log in to answer this question.

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