{"id":51918,"date":"2026-05-14T14:38:26","date_gmt":"2026-05-14T18:38:26","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=51918"},"modified":"2026-05-14T14:38:26","modified_gmt":"2026-05-14T18:38:26","slug":"apfs-folder-clones","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2026\/05\/14\/apfs-folder-clones\/","title":{"rendered":"APFS Folder Clones"},"content":{"rendered":"

Anders Borum<\/a>:<\/p>\n

\n

After my experiments with APFS cloning, I made a Quick Action shortcut<\/a> 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.<\/p>\n<\/blockquote>\n

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

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

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)<\/a> man page says:<\/p>\n

If src<\/code> names a directory, the directory hierarchy is cloned as if each item was cloned individually. However, the use of clonefile(2)<\/tt> to clone directory hierarchies is strongly discouraged. Use copyfile(3)<\/tt>\ninstead for copying directories.<\/p>\n<\/blockquote>\n\n

I don’t think APFS really supports directory clones except at the snapshot level.<\/p>\n\n

See also: Ask Different<\/a>, Howard Oakely<\/a>.<\/p>\n\n

Previously:<\/p>\n