APFS has two special file types designed to economise on storage space: clone and sparse files. Clone files are two or more distinct files within the same volume whose data is shared; sparse files save space by skipping empty data and only storing data containing information. This article explores how they behave in use, with particular emphasis on Time Machine backups and iCloud Drive. The latter also involves a third type of special file, dataless files.

Clone files

In contrast to hard-linked files, clone files are two or more distinct files within the same file system (volume) whose file extents are identical, so share the same data, as shown below. They’re created by variants of normal file copying, including duplicating in the Finder (and drag-copying within the same volume), and the cp -c command.

Instead of duplicating everything, only the inode and its attributes (blue and pink) are duplicated, together with their file extent information. You can verify this by inspecting the numbers of those inodes, as they’re different, and information in the attributes such as the file’s name will also be different. There’s a flag in the file’s attributes to indicate that cloning has taken place. At first, the two cloned files share the same data blocks and extended attributes, but as the two files are changed by editing, they start to drift apart and become uncloned.

Clone files are becoming more popular thanks to the Hyperspace app, which deduplicates files within the same volume by replacing copies with clones.

Because they can only exist within the same file system, clone files are fragile. Any copy or move to another file system is invariably accompanied by the copying of their full data, and their economy of storage can only remain as long as they stay within the same volume.

Backups

One notable exception to this same-volume rule is in Time Machine backups. As clone files are preserved in local snapshots, when Time Machine constructs a backup as a snapshot in the backup storage volume, shared file extents are retained, so preserving clones. This is reflected in the size of the backup snapshot, and in the report written to the log. For example, when backing up three distinct files and ten clones of one of those, that report included:
14 Total Items in Backup (l: 16 GB p: 11.02 GB)
3 Files Copied (l: 6 GB p: 1.02 GB)
1 Directories Copied (l: Zero KB p: Zero KB)
10 Files Cloned (l: 10 GB p: 10 GB)

Backups made by other utilities are unlikely to reproduce this behaviour, though, as they can’t synthesise snapshots in the way that Time Machine does. To preserve clone files in their backups, they’d have to identify clones in the source and explicitly perform cloning in their backup store. Although Carbon Copy Cloner claims that “in some cases CCC may clone a file on the destination prior to updating its contents”, it doesn’t appear to attempt to preserve clone files in the backups it makes. I’m not aware of any third-party utility that does.

Unfortunately, Time Machine appears unable to restore directly from backup snapshots in the backup store, and performs Finder copies when restoring. That saves each of those clone files as a completely separate file, without any sharing of data. As a result, the space occupied on disk for a restored volume can be substantially greater than the original or its backup. Extensive use of clone files could thus cause problems when restoring from backups.

Of course, rolling a volume back to a local snapshot, such as one made during Time Machine backups, preserves all clone files within that volume.

iCloud Drive

Clone files created within the same volume as local iCloud Drive storage on the Data volume, or cloned when within a folder in iCloud Drive, remain within the same file system and clones are therefore preserved, and when the file is moved to other folders in the same volume.

However, clone files are treated as simple copies as far as iCloud Drive’s remote storage is concerned. While a pair of cloned 5 GB files only use a total of 5 GB local storage, they require a full 10 GB of your iCloud allocation, indicating that their cloud storage is separate and not common to both. Although the effects of eviction (removing local data) and materialisation (restoring local data from cloud storage) are difficult to observe directly, they appear to lose the benefits of cloning.

When the local copy of a file also stored remotely in the cloud is evicted, its data is removed from local storage, rendering it dataless, as shown below.

When that file is to be used locally again, its data has to be downloaded from the cloud service, and the local dataless file is materialised by adding its data back. As far as I can tell, that doesn’t result in the reconstruction of the shared file extents, so changes cloned files into normal copies with different file extents. You would then need to use Hyperspace to restore them as clone files. Other Macs sharing the same iCloud Drive also see them as full copies rather than clones.

These behaviours could also catch the user by surprise.

Sparse files

Unlike clone files, the structure of sparse files in APFS is conventional, as shown below.

They achieve their economy in storage by only including file extents containing non-null data, and thus aren’t dependent on remaining within the same file system (volume), making them more robust. Their primary requirement is that they’re created and maintained using specific file system operations, and are only copied or moved to other APFS file systems.

Backups

When backed up by Time Machine to another APFS volume, sparse files are preserved reliably, and are also restored as sparse files. That isn’t likely to hold, though, if the file is transferred using a network file system such as SMB, as all network transfers currently appear to explode sparse files to full size prior to transfer. Because of the way in which they have to be created, only the app maintaining that file could restore its sparse format. In the case of disk images, this should normally occur the next time they’re mounted in the Finder and Trimmed by APFS.

iCloud Drive

Assessing what happens with sparse files in iCloud Drive is considerably simpler than with clone files. As long as they remain downloaded to local storage, they are preserved, and can be moved in and out of iCloud Drive storage without exploding in size. However, they too are stored in full when in iCloud storage, requiring their full size in your iCloud allocation, and the eviction-materialisation cycle explodes them to full size, and their sparse file flag is removed.

The only way to return a former sparse file to its original economical format is then to open and save it using the app that creates and maintains it. In the case of disk images, this should occur when they’re next mounted and Trimmed.

Conclusions

Clone files:

• are only preserved when moved within the same file system (volume);
• are preserved and restored from local snapshots;
• are preserved in Time Machine backups, but aren’t restored from them;
• aren’t preserved in other backups;
• could result in a restored volume being substantially larger than its original;
• occupy their full space in your iCloud allocation;
• are only preserved in iCloud Drive when they aren’t evicted from local storage;
• can be regenerated using Hyperspace.

Sparse files:

• are only preserved when copied or moved directly between APFS volumes;
• aren’t preserved when copied or moved over network connections, or using SMB;
• aren’t preserved when copied or moved to different file systems, including HFS+;
• are preserved in and restored from local Time Machine backups;
• should be preserved in and restored from other local backups;
• occupy their full space in your iCloud allocation;
• are only preserved in iCloud Drive when they aren’t evicted from local storage;
• can only be regenerated by the app that creates and maintains them.

Both clone and sparse files can result in substantial savings in storage space. However, because that’s fragile, their greatest value is in minimising erase-write cycles in SSDs, hence slowing their ageing.

References

Apple’s APFS Reference (PDF), last revised 22 June 2020.
Dataless files are explained here.
How sparse files work
Files and clones
Special file types, including dataless files

I’ve long been critical of some of the best-selling utilities for the Mac, that set out to perform deduplication of files by detecting which appear to be identical, and removing ‘spare’ copies. This is because APFS introduced clone files, and in the right circumstances those take up no space in storage, as their data is common and not duplicated at all. As it’s practically difficult to tell whether two files are clones, any utility or command tool that claims to save space by removing duplicates can’t tell you the truth, and in most cases won’t save as much space as it claims.

Claims made by those utilities are often exaggerated. This is because they calculate how much space they think they’ve saved by adding the sizes of the potential duplicates they have deleted. That’s not correct when a clone file is deleted, as that doesn’t actually free any space at all, even though the clone file has exactly the same nominal size as the original.

Benefitting from clone files

I’m delighted to see the eminent John Siracusa turn this on its head and finally make better use of clone files in his app Hyperspace, available from the App Store. Instead of deleting clones, his app can replace duplicate copies with clones, and so achieve real space savings. This comes down to simple arithmetic:

• if you have two copies (not clones) of a file in the same APFS volume, the total size they take on disk is twice the size of one of them;
• if you have two clones (not copies) of a file in the same APFS volume, the total size they take on disk is only the size of one of them, as its clone takes no additional space at all.

Hyperspace thus checks all the files in a selected folder, identifies which are identical copies, and (where suitable) will replace those copies (except an original) with clones, so saving real storage space.

I also think it has the most user-friendly payment scheme: download Hyperspace free of charge and check your Mac with it. If it doesn’t find sufficient savings, and you decide not to use it to replace any duplicates with clones, then it costs you nothing. If you want to reclaim that space, then you can opt to pay according to the amount of space it saves, by subscription, or with a one-time payment. On that basis, I unhesitatingly recommend everyone to download it from the App Store, and at least check their Home folder to see if it’s worth paying to reclaim space. You have absolutely nothing to lose.

In my case, perhaps because I tend to clone files using the Finder’s Duplicate command, the savings that it offered were of little benefit, but your Home folder could be different and release 100 GB or more.

Sparse files

The other space-saving special file type in APFS is the sparse file. Although it can bring great savings in storage space, that’s largely up to the app(s) that create and maintain the file, rather than the user. Devising an app that could go round converting plain to sparse files is harder, and risks incompatibility with those apps that access those files.

Fitting 285 GB into 16.5 GB

As a demonstration of how effective APFS special files are in saving disk space, I built myself a 100 GB partition (APFS Container) on an SSD and tried to fill it with clone and sparse files until I got bored.

At this stage, the 100 GB partition contains:

• One 16.5 GB IPSW image file, with nine clones of it, created using the Duplicate command.
• Eleven 10 GB sparse files and one clone, created using my app Sparsity.

Add those file sizes together and they come to 285 GB, yet the 100 GB partition only has 16.5 GB stored on it, and still has over 83 GB free. No compression is involved here, of course.

As the saying goes, there ain’t such as thing as a free lunch, and that free space could vanish quickly depending on what happens to those files. The worst case is for an app not to recognise sparse files, and write one to disk in plain format, so swallowing 10 GB at once. Editing the cloned files would be a more gradual way of their growing in size. Only changed data would then need to be saved, so free disk space would steadily fall as more changes were made to the clone.

Clone and sparse files are by no means unique to APFS, but they can be impressive, and above all they’re effective at reducing excess erase-write cycles that age SSDs, whatever you do with the storage they free.

I’m very grateful to Duncan for drawing my attention to Hyperspace, and to John Siracusa for an outstanding app.

Apple has gone to great lengths to make the transition to its new Arm-based Macs as seamless as possible. However, there are some major differences that most need to take into account before making their leap of faith from a cherished but now-ageing Intel Mac to a sleek and glitzy new M-series Mac. This article clarifies what are often points of confusion about what you can’t or shouldn’t do with a new Apple silicon Mac.

You can’t run any macOS before Monterey (or possibly Big Sur)

There are two ways to run macOS on Apple silicon Macs: natively, or in a virtual machine (VM). The oldest version of macOS your Mac can run natively is that current at the time that model was released. Models released before October 2021 can run macOS 11 Big Sur, and are the only Apple silicon Macs that can do so. Those released from October 2021 onwards can only run the version of macOS that was current at the time of their release, but can run older versions back to macOS 12 Monterey in a VM. Current models with M4 chips are even more restricted, as the earliest version they can run is macOS 15 Sequoia, although their VMs can still stretch back to Monterey if you need.

Catalina, Mojave and earlier were never released with support for Apple silicon Macs, so can’t be run on them, and will never be able to without emulating Intel processors in software, which is slow and unreliable.

A VM running on an Apple silicon Mac can’t run Big Sur, because the Virtio driver support required for virtualisation wasn’t complete then, and didn’t work until macOS 12 Monterey, although even there it offers fewer features than in Ventura. Full details are given here.

You can’t virtualise or run Intel macOS or 32-bit apps

Bundled in macOS is Rosetta 2, enabling you to run 64-bit Intel code and apps that are compatible with macOS 10.15 Catalina. Rosetta isn’t an emulation engine, but translates code from Intel to Arm instructions. However, it can’t translate 32-bit code, and it can’t translate operating systems like macOS. It does run 64-bit Intel apps amazingly quickly, though.

A VM running macOS on Apple silicon can therefore use Rosetta 2 to translate and run 64-bit Intel code in apps that are compatible with macOS 10.15 Catalina, but is subject to the same limitations as any version of macOS on Apple silicon, in that it can’t handle older or 32-bit apps. Neither can it be used on the host Mac to run a VM of any Intel version of macOS.

If you need access to older or 32-bit Intel software, then the only practical way of doing that is on an Intel Mac that’s able to run Mojave or earlier.

You can’t install Intel kernel extensions

Rosetta 2 translation can’t support the privileged level of execution required for kernel extensions, so if you need your Mac to be able to load and use kernel extensions that are only available for Intel Macs, you can’t do that on an Apple silicon Mac. The great majority of more recent kernel extensions are now available as Universal versions that can also run native on M-series chips, but if your Mac still relies on an older kernel extension that’s Intel-only, then you can’t use that on a new Mac.

You can’t boot fully from an external drive

Unlike Intel Macs, Apple silicon models can only start their boot process from their internal SSD, as that’s required to support their Secure Boot. Although Apple silicon Macs can boot from external disks, early phases of that process still rely on the internal SSD and security policies (‘LocalPolicy’) saved there. This has several consequences:

• An Apple silicon Mac can only boot from an external disk that is ‘owned’ by a user recognised by the primary system on its internal SSD. This is a valuable security measure, as without knowing login details for a suitable user of the internal SSD, it’s not possible to boot an Apple silicon Mac from an external bootable disk.
• An Apple silicon Mac can only boot from an external disk if it can at least start that process from its internal SSD, normally requiring a bootable system on the internal SSD as well. If you do intend booting your Mac from an external disk, in practice you still need to install and maintain a bootable system on its internal SSD.
• Total failure of the internal SSD results in failure to boot from external disks as well. A bootable external disk can’t ‘get you home’ in that emergency.
• Apple silicon Macs don’t really boot fully from ‘bootable’ external installer disks, although they can still be used to install macOS when necessary, and may be required when installing older versions of macOS than currently installed.

Instructions for installing macOS on an external disk so that it can boot an Apple silicon Mac are given here.

You can’t use Boot Camp

Boot Camp allows you to start up an Intel Mac as if it’s a regular PC to run Windows. As Apple silicon Macs have completely different processors and other hardware, they can’t support that option. If you want to run Windows on your Apple silicon Mac, you’ll have to do that using a virtualiser like Parallels Desktop, and currently those can only run Arm versions of Windows, although Parallels is working on an emulator that can run some Intel versions. You can already try that out.

Avoid kernel extensions

Unlike Intel Macs, Apple silicon Macs don’t allow the use of third-party kernel extensions when running in Full Security mode. Before it can have those enabled, its startup security has to be reduced, and their use explicitly set in Startup Security Utility in Recovery mode. For most users that’s a significant deterrent. In almost all cases now, traditional kernel extensions should be replaced by new-style system extensions. You can read more about that here.

Avoid ‘cloning’ boot volume groups

Before Catalina and Big Sur divided the boot volume into a group of volumes, including System and Data, it was popular to make identical copies of, or ‘clone’, the volume containing the system. This is even more complex with Apple silicon Macs because of the multiple containers on their internal SSD. Although apps like SuperDuper and Carbon Copy Cloner can still create clones, they can’t include the whole of the internal SSD. That limits their usefulness, and they can readily fail.

The only way you can completely replace the contents of the internal SSD of an Apple silicon Mac is to restore it from an IPSW image file when the Mac is in DFU mode. That erases the SSD so that its Data volume then has to be restored from a backup or copy, not a task to be undertaken lightly or in a hurry. This is explored in detail here.

Don’t try using startup key combinations

Entering Recovery mode and accessing features that are controlled using startup key combinations on Intel Macs is completely different in Apple silicon Macs, and controlled using the Power button. Holding keys during startup does nothing for an Apple silicon Mac. I have an illustrated guide, details on Fallback Recovery, and on troubleshooting.

Neither can you reset the PMC or NVRAM using startup keys. The PMC in an Apple silicon Mac is completely different, and shouldn’t need to be reset. If it does, then restarting should suffice. NVRAM is primarily for the use of macOS not the user, and you should never have to reset it. Further information is given here.

Further reading

My page listing articles specific to Apple silicon Macs contains extensive information and guidance.