CCC is fully compatible with macOS Ventura and Sonoma. We're tracking the following issues specific to some OS versions.
ExFAT filesystem corruption on macOS Ventura
We're tracking a new ExFAT-specific filesystem bug in macOS Ventura. We have seen a handful of cases where a folder's inode number is identical to the inode number of its parent folder. Some filesystem enumeration facilities (e.g. fts) identify this (correctly) as an insane "directory cycle" (i.e. infinite loop) condition and refuse to enumerate the content of the corrupted subfolder. CCC (6.1.4+) identifies this result, reports it as an error, and suspends any deletion/archival activity on the destination when this condition is encountered to avoid errantly removing content from the destination that was copied in a previous backup task.
In the handful of cases we're tracking, the issue appears to be both transient and recurrent, e.g. sometimes the condition is absent when running the task again at a later time, and sometimes it recurs immediately after remounting the source volume. We have seen other related aberrant behavior on these volumes, e.g. folder inode numbers change when the volume is remounted. These aberrations are harmless as far as a backup/file copying task is concerned, but could cause trouble for other applications that expect folder inode numbers to be constant.
We consider this a serious filesystem bug, however we are not concerned that this will lead to data loss on ExFAT source volumes. This bug is exposed only when performing a complete enumeration of the volume starting from the root folder, it's not something that would necessarily affect the collection of an individual folder's content (e.g. in the Finder). Regardless, this condition is not sane and could lead to unexpected results from applications that are not guarding against this kind of filesystem corruption. Our recommendation right now is to avoid using ExFAT on macOS Ventura if you're not specifically using that filesystem to share files with a non-macOS device. Except when required to share files with a non-Mac system, ExFAT is generally a poor choice on macOS. It's very slow on macOS (usually 2-4x slower than APFS), and uses space much less efficiently.
We have reported this bug to Apple (FB11834215, November 29, 2022).
Update October 2023: Apple reports that this issue is resolved in macOS Sonoma. If you're seeing this corruption, then our primary recommendation is to upgrade to Sonoma, if possible.
Workaround: A "folder swap" on the source should resolve individual occurrences of this problem. For example, if CCC identifies that a folder named "Projects" is affected, then you would:
- Create a new folder adjacent to "Projects" named "Projects-new" [on the source volume]
- Move the content of "Projects" into the "Projects-new" folder
- Move the (now empty) "Projects" folder to the Trash
- Rename "Projects-new" to "Projects"
- Run your CCC backup task again to complete the backup
Solution: After you have resolved any corrupted folder issues (see above), you can do the following to migrate your data away from the ExFAT volume:
- If your destination is also ExFAT formatted, erase that volume in Disk Utility using the APFS format
- Run your CCC backup task again to complete an error-free backup
- Click the Compare button in CCC's toolbar to verify that the content of the destination matches that of the source
- Erase the affected source volume in Disk Utility using the APFS format
- Click Restore in CCC's toolbar to configure a new task to restore your data to the new volume from the backup
If you have any concerns about this procedure, or you would like a review of your case prior to erasing the source, please don't hesitate to ask us for help. We greatly prefer to get involved before you erase your source if you have any questions or nagging concerns about the procedure.
Apple's APFS replication utility ('asr') may fail to produce a bootable USB device on Apple Silicon Macs
When using the Legacy Bootable Copy Assistant on an Apple Silicon Mac running macOS Ventura or later, the resulting volume may not be bootable if it resides on a USB-attached device. ASR can produce bootable copies to the same device on an Intel Mac. This does not appear to be a general shortcoming of USB devices on this platform, rather it appears to be a shortcoming of the Apple asr utility.
Workaround: Use a Thunderbolt device if you're trying to make a bootable copy of macOS on an Apple Silicon Mac.
Workaround: If you only have access to a USB device, proceed with a Standard Backup (do not use CCC's Legacy Bootable Copy Assistant). When the backup is complete, open the macOS Installer (or boot into Recovery Mode) and proceed to install macOS onto the USB device.
Finder will not show, nor allow you to set custom icons on macOS startup volumes
Finder will show and allow you to customize the volume icon for your current startup disk, but not for other startup volumes that your Mac is not currently booted from. This problem is not specific to CCC nor the manner in which CCC makes legacy bootable copies of the system, rather it is the result of a design flaw in the implementation of custom icons in an APFS volume group. Long ago the custom volume icon was stored in a file at the root of the startup disk named ".VolumeIcon.icns". To keep the System volume read-only, yet allow the apparent modification of this icon file, Apple chose to create a symbolic link at the root of the startup disk that points to System/Volumes/Data/.VolumeIcon.icns. For the current startup disk, this path resolves correctly because the Data member of the volume group is mounted at /System/Volumes/Data. That's not the case for external volumes, those Data volumes are mounted at /Volumes/Bootable Copy - Data (for example). As a result, the symbolic link to .VolumeIcon.icns is unresolvable for any volume that is not the current startup disk.
We reported this issue to Apple in May 2020 (FB7697349). We do not anticipate a response nor solution.
Alternative: We recommend creating "Standard" backups instead of creating a legacy bootable copy. Finder will issue no challenges to customizing the icon of a volume with a Standard Backup.