cp --parents on Mac: rsync -R, ditto and the ../ Trap

On Linux, cp --parents a/b/file.txt backup/ copies the file to backup/a/b/file.txt and makes the folders on the way. On a Mac, the same line stops at the first dash:

$ cp --parents src/a/b/file.txt out/
cp: illegal option -- -
usage: cp [-R [-H | -L | -P]] [-fi | -n] [-aclpSsvXx] source_file target_file
       cp [-R [-H | -L | -P]] [-fi | -n] [-aclpSsvXx] source_file ... target_directory
$ echo $?
64

The macOS cp is the BSD one, and --parents is a GNU extension it never had. The question has been asked since 2012, and the Stack Overflow thread (37,491 views when I pulled it today) has two popular answers: rsync -R with 106 votes and ditto, the accepted one, with 19. The accepted answer on Ask Different offers rsync -R or GNU gcp. I ran both of them and six other ways to do it on this Mac mini (macOS 26.4.1), against GNU gcp from coreutils 9.12, using a test tree with a space in one folder name, a 700 parent folder, an extended attribute and a 2020 timestamp. Most of them copy the path. They differ on what they drop and on what they do with a path that starts with ../.

What each one does with two files

The test was two files, src/a/b/file.txt and src/c d/my file.txt, copied into an empty folder. "Keeps paths" means both landed under out/src/…. The other columns are what I read back with xattr -l and stat afterwards.

Command	Keeps paths	xattrs	mtime	Parent folder mode	Missing destination
cp --parents	illegal option, exit 64
gcp --parents	yes	kept	reset (kept with -a)	copied, even without -a	error
rsync -R	yes	dropped (kept with -E)	reset (kept with -a)	755 (copied with -a)	created
ditto a b dir/	no, flattens	kept	kept	755	created
pax -rw	yes	kept	kept	755	error
tar c | tar x	yes	kept	kept	755	not tested
cpio -pdm	yes	dropped	kept	755	not tested
mkdir -p + cp -p	yes	kept	kept	755	created
install	"No such file or directory", exit 71

Three things in that table go against what the threads say.

The accepted answer only works for one file. ditto src/a/b/file.txt out/src/a/b/file.txt makes the folders and keeps everything. That's the "src_file dst_file" form in man ditto. Give it two files and a folder, which is how cp --parents is used, and you get out/file.txt and out/my file.txt with no folders. Exit 0, no warning. So ditto is only a replacement if you write out the full destination path for each file.

Stock rsync -R drops extended attributes. /usr/bin/rsync on recent macOS is openrsync, not Samba rsync (I counted 42 rejected flags in the macOS rsync last month). Plain -R copied the paths but not com.test.tag, and -a doesn't add it. The flag is -E, Apple's own. -X, the one you'd type on Linux, fails with invalid option -- X. rsync -aRE kept all four things the table checks.

gcp --parents copies the parent folder's mode even without -a. src/a was 700, and out/src/a came out 700 too. That's usually fine, until a parent folder is read-only. Then it breaks the second copy.

The read-only folder problem

A 2015 Unix & Linux question describes it: copy one file out of /lib with --parents, then a second one, and the second fails because the first created a read-only lib. It reproduces on the Mac with gcp:

$ chmod 555 ro/lib
$ gcp --parents ro/lib/one g1/; echo $?
0
$ gcp --parents ro/lib/two g1/; echo $?
gcp: cannot create regular file 'g1/ro/lib/two': Permission denied
1
$ rsync -aR ro/lib/one r1/ && rsync -aR ro/lib/two r1/; echo $?
0

rsync -aR copied both files and still left r1/ro/lib read-only at the end, as the accepted answer there says. Plain rsync -R made the folder 755, so it never hit the problem.

The ../ trap: gcp writes outside the destination

This one I didn't expect. GNU's cp manual defines --parents exactly: it forms each destination name "by appending to the target directory a slash and the specified name of the source file." It doesn't clean up the result. So when the source path starts with ../, the destination does too:

$ cd deep/w
$ gcp --parents ../../src/a/b/file.txt ../../out15/; echo $?
0
$ find ../../out15
../../out15
$ ls /tmp/src/a/b/
file.txt

Exit 0, the destination is empty, and the file is in /tmp/src, which is outside the lab folder. out15/ plus ../../src/… climbs two levels above out15. If that path already held a file with the same name, gcp would have overwritten it.

The macOS rsync refuses the same command instead:

$ rsync -R ../../src/a/b/file.txt ../../out14/; echo $?
rsync(43646): error: ..: security violation: backtracking pathname
rsync(43645): error: unexpected end of file
1

That's the better failure. With either tool, the fix is the same: cd into the folder you want the paths to be relative to, and pass paths that don't start with ../. Absolute paths don't escape, but they copy the whole path. gcp --parents /tmp/cplab/src/a/b/file.txt out12/ made out12/tmp/cplab/src/…, and rsync -R did the same.

Picking where the path starts

Usually you don't want src/ in the copy, only a/b/file.txt. Samba rsync lets you mark the start with /./, as in src/./a/b/file.txt. The macOS openrsync ignores it: that call made out4/src/a/b/file.txt, the same as without the dot. A subshell works with everything in the table:

(cd src && rsync -aRE "c d/my file.txt" a/b/file.txt ../backup/)
# backup/c d/my file.txt
# backup/a/b/file.txt

For a list of files, such as the output of git diff --name-only, --files-from takes paths relative to the source argument and keeps them, spaces included:

find src -name '*.txt' > list.txt
rsync -aE --files-from=list.txt . backup/

That's also safer than looping cp through xargs, which on macOS has a few differences from GNU of its own.

What I'd use

• A script that has to run on any Mac: rsync -aRE from inside the source folder. It's in the base system, keeps the four things the table checks, refuses ../, and handles read-only parents. If the script also has to run on Linux, drop the E. Samba rsync there uses -X, and -E means something else (keep executability).
• A shell loop you can read in a year: mkdir -p "out/$(dirname "$f")" && cp -p "$f" "out/$f". It's slower, but every step is visible, and it kept xattrs and mtime here.
• Linux scripts you don't want to touch: brew install coreutils and change cp to gcp. Just don't feed it ../ paths.

Avoid the basename loop from the Super User thread: it drops the folders, which is the opposite of what you asked for. Avoid ditto with more than one source. And since install on macOS doesn't make missing folders, it fails with exit 71.

This is the fourth GNU-vs-BSD gap I've measured on this Mac, after stat's -c, head's negative counts and ln's missing -r. They share a pattern: the error is the easy case. The trouble is the substitute that exits 0 and does something slightly different. Here that's ditto flattening a list, and gcp writing outside the destination.

Sources: every command and output above was run on 2026-10-03 on a Mac mini (macOS 26.4.1, build 25E253) in a throwaway folder under /tmp, using /bin/cp, /usr/bin/rsync (openrsync, protocol 29), ditto, pax, tar, cpio, install, and gcp from GNU coreutils 9.12 (Homebrew). Extended attributes were checked with xattr -l against a test attribute I set, and modes and times with stat. Vote and view counts for the Stack Overflow, Super User, Ask Different and Unix & Linux threads come from the Stack Exchange API on the same day. The --parents definition is quoted from the GNU coreutils manual. "Not tested" in the table means I didn't run that case. I didn't guess it from documentation.