Duplicate a 40 GB video file in Finder on a Mac running APFS and it finishes almost instantly, with no visible drop in free space. That is not a trick or an optimistic progress bar — it is APFS creating a clone, a second file that points at the same underlying data blocks as the original rather than physically copying forty gigabytes of bytes to a new location. Both cp -c from the terminal and a plain Finder duplicate use this mechanism on APFS volumes, and understanding how it works explains some genuinely surprising things about how Mac storage numbers behave after you copy things.
What actually happens when you duplicate a file
Every file on an APFS volume is described by metadata that points to the specific data blocks on disk containing its content. When you duplicate a file the ordinary way — copying bytes into a new file — the system has to read every block of the original and write a fresh copy of each one to a new location, which takes time proportional to the file's size and genuinely doubles the space it occupies.
An APFS clone skips almost all of that. Instead of copying the data blocks, it creates a new file entry whose metadata points at the exact same blocks as the original. Two files, two names, two independent entries in the directory structure — but, for the moment, one shared set of data on disk. Because no data actually moved, the operation completes in roughly the time it takes to write a small amount of metadata, regardless of whether the file is one megabyte or one hundred gigabytes.
Why this makes duplication both instant and free
The speed is the more obvious consequence: cloning a file involves none of the disk I/O that copying its actual content would require, so it finishes at a speed governed by metadata operations rather than file size.
The storage consequence is less obvious but arguably more important for understanding what your Mac reports about free space. Immediately after a clone, the two files together do not occupy roughly double the original's size — they occupy, in real terms, close to what the single original occupied, because they are still sharing the same blocks. This is why you can duplicate a very large file on an APFS volume and watch the reported free space barely change, which looks wrong if you are expecting a straightforward copy but is entirely correct given what actually happened on disk.
How the clone "breaks" and starts costing real space
The sharing arrangement lasts only as long as both files remain identical. The moment either the original or the copy is modified — even a small edit — APFS cannot simply update the shared blocks in place, because that would silently change the other file too, which is obviously not what a copy is meant to do. Instead, APFS applies copy-on-write at the level of the specific blocks affected by the change: only the blocks that differ after the edit get physically duplicated and written separately, while every block that is still identical between the two files continues to be shared.
This is a genuinely granular process. Editing a small section in the middle of a large cloned video file, for instance, causes only the blocks covering that edited section to become independently allocated; the vast majority of the file, still unchanged, remains shared with the other copy. The clone does not "break" all at once — it breaks incrementally, one changed region at a time, and the additional storage cost is proportional to how much actually changed, not to the size of the whole file.
Where you will actually encounter this
Finder's ordinary Duplicate command (Cmd+D, or right-click → Duplicate) on a file that lives on an APFS volume uses cloning automatically — there is no separate menu item for it, it is simply how duplication works on this filesystem. From the terminal, cp -c <source> <destination> explicitly requests a clone rather than a byte-for-byte copy, which is useful when you want to be certain the operation will be instant and initially space-free rather than relying on Finder's default behaviour.
This matters in ordinary situations more often than it might seem: duplicating a large project folder before making risky changes, keeping a backup copy of a virtual machine disk image before an update, or creating a second version of a big media file to edit separately. In each case, the clone mechanism is why the operation does not visibly cost you disk space or time up front.
What this means when you are trying to understand disk usage
Clones are part of why a simple sum of "nominal file sizes" across a drive can overstate how much space is actually used, and conversely why the space genuinely freed by deleting one of two cloned files can be far smaller than the file's reported size, if most of its blocks are still shared with the surviving copy. A storage tool that only reports the nominal size of each file, without accounting for shared blocks, will not accurately reflect how much space deleting something will actually free — which is a distinct and separate issue from hard links, though the underlying idea of "multiple names pointing at shared data" rhymes with clones in spirit.
Recognising a clone situation is mostly about not being surprised: if duplicating something huge finished suspiciously fast and free space barely moved, that is APFS working exactly as designed, not a sign that the copy failed or that something is wrong with the disk.
Conclusion
APFS clones are one of the more elegant pieces of engineering sitting quietly underneath everyday Mac use — they make routine duplication essentially free until you actually need two independent copies, at which point the filesystem starts charging you only for what genuinely changed. It is a good example of a storage behaviour that looks like a bug the first time you notice it and is actually the system working correctly.
Because clones and shared blocks complicate what "how much space is this file using" really means, we built VolumeLens to show both nominal size and actual on-disk usage rather than collapsing the distinction, so the numbers you see reflect what deleting something would genuinely free rather than a simplified guess.