"Container object map B-tree is not of the Physical storage type"

[jeremy-admin]

Hi @jivanpal.

Thank-you for drat. I don't want to waste your time unnecessarily, so will start with only a short post.

My 2009 Unibody Macbook shutdown unexpectedly one day recently, and failed to recognise the start-up disk subsequently. drat-0.1.3-linux-amd64 inspect happily runs until it exits with the message below.

Can this error be recovered from? In other words, should I invest any more effort in trying to resurrect this disk?

Much obliged for your work and any reply,
sincerely
Jeremy

The container superblock states that the container object map has Physical OID 0xbcb6c.
Loading the container object map ... OK.
Validating the container object map ... OK.

Details of the container object map:
--------------------------------------------------------------------------------
Stored checksum:    0xcbfca6fb20c7828f
OID:                0xbcb6c
XID:                0x8593f
Storage type:       Physical
Type flags:         (no flags)
Type:               B-tree (non-root) node
Subtype:            Extent references tree
Flags:
- Transitioning to encrypted state
Object mappings tree:
- Storage type:         Virtual
- Type flags:           (no flags)
- Type:                 (invalid type / no subtype)
- Object ID:            0xffff0000ffff
Snapshots tree:
- Storage type:         Virtual
- Type flags:           (no flags)
- Type:                 Unknown value (0x380)
- Object ID:            0x14039800080168
- Number of snapshots:  112 snapshots
- Latest snapshot XID:  0x14065400080280
In-progress revert:
- Minimum XID:          0x14066800080288
- Maximum XID:          0x14067c00080290
--------------------------------------------------------------------------------

END: The container object map B-tree is not of the Physical storage type, and therefore it cannot be located.

[jivanpal]

Hi, Jeremy,

It's very possible that object maps from older APFS transactions are intact. If not that, it's still extremely likely that your filesystem tree and file data are still recoverable. Unfortunately I have not been able to find the time to continue working on Drat so far this year, but indexing the entire disk to find any/all recoverable data is the next real feature that I would like to implement. In the meantime, you may like to backup the disk's current contents for later inspection, and/or try out other recovery tools such as Disk Drill (no affiliation).