DiskWarrior might rise from the dead

I am working through all the software I have on my old MacBook Pro to prepare for install on my new
MacBook Pro that will arrive soon. Been a long time since I checked up on DiskWarrior. Found this:
“The next major release of DiskWarrior (DiskWarrior 6.0) will include the ability to rebuild APFS disks and run from M1 (ARM) equipped Macs. Apple released a majority of the APFS format documentation in June of 2020 . Our developers are now using this documentation to update DiskWarrior in order to safely rebuild Apple File System (APFS) disks.” https://www.alsoft.com/diskwarrior5apfs

5 Likes

According to Wayback Machine, that same paragraph has been there since at mid-January of this year, so I wouldn’t hold my breath.

I will not be holding my breath, but I am happy to hear that DiskWarrior, an old friend, is showing signs of reincarnation.

No company wants to be forced out of business by their flagship product becoming moot.

I’m sure they’re working on an APFS-compatible version of Disk Warrior, but these kinds of tools are very hard to get right and Apple has not been forthcoming with documentation for the ugly implementation details needed to make it work without massive amounts of reverse-engineering.

I just hope they can pull it off before the company runs out of money.

There’s a 181 page PDF available with pretty detailed, low-level (C structs and #defines of constants) information on the file system format including containers, volumes, encryption, B-Trees, etc. I played around with it for half a day a while ago and even wrote a little perl script to dump formatted file system information. Maybe it’s not sufficient to write a repair utility, but it is pretty extensive.

They have to deliver a product that is without bugs and that gives you something more than Disc Utility. No easy task.

APFS is supposed to be more reliable than HFS. I wonder if on APFS, the Venn diagram of “damage that actually occurs” and “damage that is possible to fix” has no intersection?

Also, think of the point of DiskWarrior: it doesn’t repair damage. What it does is construct a new directory, that doesn’t have the damage. Is that technique possible on APFS?

1 Like

It should always technically be possible, but it could be (probably is) far more difficult than rebuilding HFS+ volumes. The problem is that APFS introduces many new concepts that must be thoroughly understood in order to rebuild everything correctly. This includes:

  • Reference-counted disk blocks, including copy-on-write semantics
  • Snapshots. Every volume has multiple (maybe hundreds or even thousands) of directory systems, each one partially sharing disk blocks with the others.
  • Firmlinks. Special kinds of links used to tie locations on the System volume to corresponding locations on the Data volume. Necessary for a Catalina or later system to boot properly.
  • Volume groups. Another key concept that ties multiple volumes (especially System and Data) together on Catalina+ systems.
  • Sealed snapshots. Big Sur doesn’t boot from the System volume, but from a cryptographically signed (“sealed”) snapshot of that volume. Is it possible at all to rebuild that directory without breaking the seal and rendering the volume non-bootable?
  • Shared free space. All volumes in an APFS container share the same pool of free blocks. Because of this, is it possible to rebuild one volume without rebuilding every volume in a container?

I’m sure Alsoft is aware of all of these issues. And I’m sure they have ideas (if not yet fully tested code) for how to deal with them. But they are difficult problems, so I’m not surprised it is taking a long time to develop a useful and reliable rebuild tool.

2 Likes