[macOS] Fix COPY step on macOS 15 Sequoia

[cbracken]

macOS build fails on Sequoia beta 2 and later (verified in public beta 3 as well) hosts during ninja COPY steps when copying files with the restricted extended attribute set. As part of our build, we copy the /System/Library/Fonts/Apple Color Emoji.ttc which is one such file.

The problem appears to be due to the -a (archive) option, which is an alias for -RpP. Of these, the -p option appears to be the source of the problem. This flag attempts to preserve file metadata including Access Control Lists and Extended Attributes. However, the restricted extended attribute is not settable when System Integrity Protection (SIP) is enabled, which it is by default.

This appears to be a change in the implementation of cp in macOS 15 Sequoia beta 2 and later. Previous versions would fail to copy the attribute, but continue without failing. The current version appears to fail if it cannot set a given extended attribute.

Two alternatives to the previous cp -af step:

• Use cp -Rf. This succeeds but file metadata such as creation time, modification time, etc. are not preserved.
• Use rsync -arl. rsync's -a flag also copies metadata but on a best-efforts basis and doesn't error out when it fails to set the restricted attribute.

Of the two, the latter more closely approximates the previous behaviour.

Fixes: flutter/flutter#152978

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read the Flutter Style Guide recently, and have followed its advice.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[jmagman]

1. man rsync says -a is the same as -rlptgoD so do we need the rl?
2. Instead of the rm -rf we can use rsync --delete so it will only copy what's needed, but delete anything extraneous (this is what we do in the tool)
   https://github.com/flutter/flutter/blob/0a7f8af6d14696e9086cdd390792f7eb8a9cefa5/packages/flutter_tools/lib/src/base/os.dart#L458-L461

Suggested change

	command = "ln -f {{source}} {{output}} 2>/dev/null || (rm -rf {{output}} && rsync -arl {{source}} {{output}})"
	command = "ln -f {{source}} {{output}} 2>/dev/null || (rsync -a --delete {{source}} {{output}})"

[jmagman]

Also, do you know what's up with the symlink part?

[cbracken]

so do we need the rl?

Good catch; nope, safe to remove.

do you know what's up with the symlink part?

The code is trying to be clever. The logic is basically:

1. If possible, create a hard link (notice it's not -s), deleting any existing file (because of the -f).
2. If that's not possible (e.g. the source file is on a different volume), then rm -rf the previous file and copy the file.

This logic definitely predates APFS. With APFS, copies are free (well you still pay the cost of the inodes) and the copy is materialised only if you edit the file. i.e. APFS is effectively copy-on-write. I think we can probably safely replace the whole thing unless we have bots with non-APFS volumes, but I think we should probably do that in a follow-up patch after we check our bots.

Instead of the rm -rf we can use rsync --delete

Looks like the default behaviour is --delete-before when --delete is specified, so I think this would preserve the existing behaviour exactly. Will do a quick test locally just out of paranoia.

[cbracken]

Re: APFS, looking closer at the cp code, cp only takes advantage of cloned inodes if the -c option is passed, but falls back to copyfile() if clonefile() fails, which presumably is under the same conditions as hardlinking would -- i.e. source and destination on a different volume.

I'd have to look to see if rsync takes advantage of this or not; there's no mention in the manpage.

Regardless, we should keep the ln until we can convince ourselves that just using plain rsync won't result in worse performance and more disk usage.

[cbracken]

Based on a really quick grep of rsync it doesn't appear Apple is using clonefile or passing COPYFILE_CLONE etc. to copyfile flags so tempted to keep the ln.