This behavior has been a known quantity for many, many years.
To prevent errors when a filesystem inside of a sparse image has more free space than the volume holding the sparse image, HFS+ volumes inside sparse images will report an amount of free space slightly less than the amount of free space on the volume on which image resides. This behavior is documented in Apple's hdiutil man page: The math always felt weird, but the result was right – the disk image can't practically accommodate more than 100GB of data, so the free space should reflect that. Accordingly, when you mount the disk image, it would report its own disk usage as 400GB and its free space as 100GB (even if there is literally nothing on the disk image volume). So for example, if you had created a disk image with a capacity of 500GB on a 500GB network volume, but then you added 400GB of stuff to the network volume outside of the disk image, now there's only 100GB of space for stuff on the disk image. In the past with HFS+ formatted disk images, the disk image volume would automatically adjust its free space to accommodate any differences between the disk image volume's capacity and the actual amount of free space on the underlying disk. An APFS volume's free space doesn't reflect a smaller amount of free space on the underlying disk Taking a closer look, I discovered two bugs in macOS's "diskimages-helper" service that lead to this result. Thankfully, I was just running some tests and the file that disappeared was just test data. If you've ever lost data, you know the kick-in-the-gut feeling that would have ensued. When I unmounted and remounted the disk image, however, the video was corrupted.
The whole file copied without error! I opened the file, verified that the video played back start to finish, checksummed the file – as far as I could tell, the file was intact and whole on the disk image. Curious, I copied a video file to the disk image volume to see what would happen.
Unnoticed by us, Apple, and thousands of developers, however, is a very subtle behavioral difference that is specific to APFS on a sparse disk image.Įarlier this week I noticed that an APFS-formatted sparsebundle disk image volume showed ample free space, despite that the underlying disk was completely full. As far as creating and mounting disk images is concerned, APFS and HFS+ are easily interchangeable, so adding support for APFS was very straightforward. Naturally, when Apple introduced APFS in macOS High Sierra, we sought to offer support for using APFS on destination disk images when doing so would match the format of the source volume. By formatting the disk image volume using an Apple-native format, we can do things like back up system files. macOS has been using disk images for decades, and we find them particularly useful when making backups to network volumes. They're files, but they act like a hard drive – you mount a disk image by double-clicking the file, then it behaves like it's another hard drive attached to your Mac. If you make backups to network volumes, read on to learn more.ĭisk images are handy devices. Disk images are not used for most backup task activity, they are generally only applicable when making backups to network volumes. While the underlying problem here is very serious, this is not likely to be a widespread problem, and will be most applicable to a small subset of backups. your SSD startup disk) are not affected by this problem. Note: What I describe below applies to APFS sparse disk images only - ordinary APFS volumes (e.g.
Until Apple issues a macOS update that resolves this problem, we're dropping support for APFS-formatted disk images. This week we reported to Apple a serious flaw in macOS that can lead to data loss when using an APFS-formatted disk image. Update September 24, 2018: This issue is resolved on macOS Mojave.