Anders Borum:

After my experiments with APFS cloning, I made a Quick Action shortcut for Finder that’s much faster than Duplicate or “cp -c -R”, both of which clone files individually instead of the whole tree in one go.

The regular file copying APIs also give you folders full of file clones rather than a directory clone. His shortcut runs a Python script:

The clone is made with the macOS clonefile(2) syscall, invoked directly through ctypes. clonefile asks APFS to create a new inode that shares the source’s data extents — no bytes are copied up front, the new tree just points at the same disk blocks. The two trees diverge lazily: only blocks that are later modified in one side get their own physical storage (copy-on-write).

However, it’s not clear to me what the benefit is. Aside from somehow being faster, it sounds like you end up with the same structure. The clonefile(2) man page says:

If src names a directory, the directory hierarchy is cloned as if each item was cloned individually. However, the use of clonefile(2) to clone directory hierarchies is strongly discouraged. Use copyfile(3) instead for copying directories.

I don’t think APFS really supports directory clones except at the snapshot level.

See also: Ask Different, Howard Oakely.

Previously:

• Hyperspace 1.3
• Aliases, Hard Links, Symlinks, and Copies in Mojave’s APFS

Update (2026-05-15): Kevin Elliott (via Frizlab):

[You] can basically think of cloning a directory as doing two things:

1. Pushing the copy operation into kernel, avoiding the syscall overhead of directory iteration, creation, and individual clonefile calls.

2. Preventing all changes to the source hierarchy while the operation is in progress, making the process atomic.

That second point is what makes this potentially dangerous as, in the worst case, you could theoretically panic the kernel by stalling all activity on critical locations long enough that the kernel "gives up" and panics.

Apple File System (APFS) Mac macOS Tahoe 26 Python Shortcuts

6 Comments