ditto Command on Mac: 13 Attributes vs cp, rsync and zip

The usual description of the ditto command on a Mac is "cp, but it keeps all the Mac metadata." I wanted to know which metadata, so I built a test folder with 13 things a copy can lose (an extended attribute, a quarantine flag, an ACL, a resource fork, Finder tags, the hidden flag, a symlink, a hard link pair, an old modification date, an old creation date, a setuid bit, a dotfile, an empty folder) and copied it 21 ways on my Mac mini running macOS 26.4.1.

Plain ditto kept 10 of the 13. Its first run also exited 1, left a temp file named .BC.T_dMVGOT that rm couldn't delete, and never created the file it was copying. Adding --clone fixed that and kept 12 of 13. The full matrix, the zip results, and the flags that don't do what the man page says are below.

What ditto is

/usr/bin/ditto has shipped since Mac OS X 10.0. On macOS 26.4.1 it is a 172,576-byte binary whose man page is dated March 29, 2023. It does four jobs: copy a folder tree, copy one file, create an archive (CPIO, or PKZip with -k), and extract one. The copier underneath is Apple's private BOM framework. You can see what ditto plans to hand it without copying anything by setting an environment variable the man page documents:

$ DITTO_TEST_OPTIONS=1 ditto src /tmp/out
src
/tmp/out
 copyACLs: true
 copyExtendedAttributes: true
 copyQuarantine: true
 copyResources: true
 crossDevices: true
 persistRestrictedFlags: true
 persistRootlessEAs: true
 preserveHFSPlusCompression: true

Note what isn't in that list: cloneFiles. It only appears when you pass --clone. That turns out to matter more than any other flag.

The copy matrix

Each column is one command copying the same test folder. "Y" means the attribute survived. I left out dotfiles and empty folders, because every method kept both.

Attribute	cp -R	cp -a	ditto	ditto --clone	rsync -aE	ditto -c -k then ditto -x -k	zip -ry then unzip
Custom xattr	Y	Y	Y	Y	Y	Y	-
Quarantine	Y	Y	Y	Y	Y	Y	-
Resource fork	Y	Y	Y	Y	Y	Y	-
Finder tags	Y	Y	Y	Y	Y	Y	-
ACL	-	Y	file missing, exit 1	Y	Y	Y	-
Hidden flag	-	Y	Y	Y	-	-	-
Symlink stays a link	Y	Y	Y	Y	Y	Y	Y
Hard link pair	-	-	Y	Y	-	-	-
Modification date	-	Y	Y	Y	Y	Y	Y
Creation date	-	-	-	Y	-	-	-
setuid bit	-	Y	-	-	Y	-	-

Three things stand out. First, macOS cp -R keeps extended attributes on its own, so "ditto keeps xattrs and cp doesn't" is out of date. Where ditto still wins is hard links: it was the only copier in the table that kept two names pointing at one inode. cp -a made two separate files. (tar and ditto's own CPIO archives also kept the pair; rsync -aHE kept it too, but printed openat: No such file or directory errors for ._hard1.txt and ._hard2.txt along the way.)

Second, the setuid bit. The man page says ditto keeps setuid "when run as the superuser," and as a normal user it didn't, while cp -a did. Third, only cloning kept the creation date. ditto --clone and cp -Rc both reported 2019 for a file I'd backdated with SetFile; everything else stamped it with the time of the copy.

The ACL failure: a temp file you can't delete

The test file had one ACL entry, group:everyone deny delete. Plain ditto printed this and exited 1:

ditto: /Users/sg-mini/work/slot-1500-ditto/lab/o_ditto/acl.txt: Permission denied

There was no acl.txt in the destination. There was a .BC.T_dMVGOT, two bytes, carrying the deny-delete ACL. ditto writes each file to a temp name, applies the metadata, then renames it into place. The ACL it just applied forbids the rename. rm on that leftover also fails with "Permission denied" until you strip the ACL with chmod -a "everyone deny delete" or chmod -N. It happened on every plain ditto run, six times in this session.

I checked the scope. ACLs of allow read and deny write copied fine. A folder with the deny-delete ACL also copied fine, which matters because ~/Library and ~/Public carry exactly that entry on this Mac. Only files with it fail. --nonAtomicCopies fixes it (exit 0, ACL kept), and so does --clone, presumably because a clone doesn't go through the temp-and-rename step.

Flags that don't do what you'd expect

• --noqtn left the quarantine flag on. The man page says it means "do not preserve quarantine information." The options dump shows it removes copyQuarantine, but copyExtendedAttributes stays true, and quarantine is an extended attribute. The copied quar.txt still had com.apple.quarantine. To actually drop it you need --norsrc, which also drops every other xattr, ACLs and resource forks (or run xattr -d afterwards, covered in no such xattr: com.apple.quarantine).
• --noextattr also turns off preserveHFSPlusCompression in the options dump, because transparent compression is stored in an xattr too.
• --keepParent still only works with -c. The man page's BUGS section says it "will eventually" work for plain copies. On 26.4.1: ditto: --keepParent only works with -c, exit 1.
• ditto src dst copies the contents of src, not src itself. cp -R src dst puts a src folder inside. Same names, different results.
• Merging overwrites without checking dates. I put a plain.txt dated 2030 in the destination; ditto replaced it with the 2020 source copy. Files that existed only in the destination were left alone.
• A missing parent is created. ditto src/plain.txt deep/a/b/c.txt made all three folders and exited 0, which is what people reach for when they want cp --parents on Mac for a single file.

Zipping an app: why Apple's docs use ditto

Apple's notarization guide uses /usr/bin/ditto -c -k --keepParent to zip the app. To see why, I copied Slack.app (319 MB on disk, 14 symlinks, signature valid) and zipped it three ways:

zip -r without -y follows symlinks, so every framework's Versions/Current became a second full copy: 366.5 MB, and codesign rejected the result with "bundle format is ambiguous." With -y, Info-ZIP did fine. The ditto zip has a catch of its own. Without --sequesterRsrc, it stores each file's metadata as a ._name entry right next to the file, 644 of them for Slack. ditto -x -k folds those back into xattrs. unzip writes them out as files, and codesign then reports "a sealed resource is missing or invalid" with lines like file added: .../Mantle.framework/Versions/Current/._Mantle.

On my test folder, --sequesterRsrc moved those entries into a __MACOSX/ folder instead, which is what the man page says Finder's Compress does. Anyone on Linux or Windows still gets that folder. If the zip is going to a non-Mac, leave the metadata out with ditto -c -k --norsrc; on my folder that produced 17 entries and no ._ or __MACOSX names.

One more difference showed up in the other direction. ditto -x -k on an Info-ZIP archive set my file's date to 03:04:06 instead of 03:04:05. The archive has the exact time in its extended timestamp field and an even-second DOS time; unzip used the first, ditto used the second.

Speed and disk space

Two runs on a 1 GiB file of random data and three on a folder of 10,000 files of 4 KiB each:

Command	1 GiB file	Space used	10,000 files
ditto	0.25 to 0.50 s	1 GiB	1.82 to 1.98 s
ditto --clone	0.02 s	0	1.12 to 1.17 s
cp / cp -R	0.68 to 0.83 s	1 GiB	1.49 to 1.64 s
cp -c / cp -Rc	0.015 s	0	0.92 to 0.96 s
cp -a	0.81 to 0.83 s	1 GiB	1.78 to 1.90 s
/usr/bin/rsync -a	4.77 to 4.83 s	1 GiB	1.46 to 1.52 s

Plain ditto was the slowest way to copy many small files. With --clone on the same APFS volume it took no space for the big file and was second only to cp -Rc on the small ones. Across volumes a clone isn't possible; I didn't test whether ditto falls back quietly there. The slow rsync number comes from the openrsync that macOS now ships as /usr/bin/rsync; macOS rsync version covers which rsync that is and how to tell.

What I'd type

# copy a folder on the same APFS volume, keeping everything but setuid
ditto --clone src dst

# when a clone isn't possible: avoids the deny-delete ACL failure
ditto --nonAtomicCopies src /Volumes/Other/dst

# zip an app for notarization or for another Mac
ditto -c -k --keepParent MyApp.app MyApp.zip

# zip for Linux/Windows: no ._ files, no __MACOSX
ditto -c -k --norsrc --keepParent folder folder.zip

And whatever you use, check the exit code and look for .BC.T_* leftovers. The question that sent most people to ditto, merging two similar folders on Ask Different, has ditto -V source destination as "the OSX easy way" in its accepted answer. That's fine, as long as you know it overwrites the newer file. For disk images instead of folders, see hdiutil; for archives whose names come out as octal escapes, illegal byte sequence on Mac shows ditto is the one extractor that still writes the file.

FAQ

What is the difference between ditto and cp on Mac?

On macOS 26.4.1, both keep extended attributes, resource forks and Finder tags. ditto copies the contents of the source folder rather than the folder itself, keeps hard links and the hidden flag, and creates missing parent folders. cp -a keeps the setuid bit, which ditto only keeps as root. Neither keeps the creation date unless you clone with ditto --clone or cp -c.

Does ditto preserve quarantine?

Yes, by default. The --noqtn flag did not remove it in testing on macOS 26.4.1, because the quarantine flag is an extended attribute and ditto still copies extended attributes. Use --norsrc to drop all metadata, or run xattr -d com.apple.quarantine on the copy.

How do I zip a folder with ditto?

Run ditto -c -k --keepParent folder folder.zip. Extract it with ditto -x -k to get the metadata back. Plain unzip writes the metadata as ._ files, which breaks code signatures inside app bundles; add --norsrc when the zip is for Linux or Windows.

Method: tests ran on 2026-10-09 between 15:00 and 15:10 KST on a Mac mini M4 (Mac16,10, macOS 26.4.1 build 25E253) over SSH, in a scratch folder under my work directory on the internal APFS volume. The test folder was built by a shell script (xattr, chmod +a, chflags hidden, ln, touch -t, SetFile -d) and each copy was checked by a Python script for all 13 attributes, ignoring the com.apple.provenance attribute macOS adds to every new file. Option lists come from DITTO_TEST_OPTIONS=1, which prints and exits without copying. Space used is the change in df free space after sync, so it is accurate to a few MB. The Slack.app test used a ditto copy of the installed app, checked with codesign --verify --deep --strict after each round trip. The Ask Different thread was read through the Stack Exchange API on the same day. I didn't test copies to other volumes, network shares or FAT/exFAT disks, ditto as root, --hfsCompression results, or any macOS older than 26.4.1.