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. ![]() 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 behavioural difference that is specific to APFS on a sparse disk image.Įarlier this week I noticed that an APFS-formatted sparse bundle 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. Mike Bombich: 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. Tell us what the problem is and how you found it? your SSD startup disk) are not affected by this problem If you make backups to network volumes, read on to learn more. What I describe below only applies to APFS sparse disk images. Disk images are not used for most backup task activity, they are generally only applicable when making backups to network volumes. Mike Bombich: 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. 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. Mike Bombich: Disk images are handy devices. In a recent blog post, Carbon Copy Cloner developer Mike Bombich revealed that he had uncovered a bug in the Apple File System, or APFS, as a result of his work with "sparse" disk images. Until Apple issues a macOS update that resolves this problem, Bombich Software are dropping support for APFS-formatted disk images.Īpple's APFS file system which is now part of macOS High Sierra apparently suffers from a disk image vulnerability that in certain circumstances can lead to data loss when working with sparse disk images.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |