Re: APFS: FSTREE oids on sealed volume
Re: APFS: FSTREE oids on sealed volume
- Subject: Re: APFS: FSTREE oids on sealed volume
- From: Mike Mackovitch via Filesystem-dev <email@hidden>
- Date: Wed, 28 Oct 2020 15:04:28 -0700
On Wed, Oct 28, 2020 at 03:07:20PM -0500, Joe Sylve via Filesystem-dev wrote:
> I have a question regarding the on-disk structure of sealed system volumes
> in macOS 11. When parsing the sealed system volume, I'm seeing non-leaf
> fstree nodes whose binv_child_oid does not correspond to an object id that
> is found in the volume's OMAP. Parsing the non-sealed volumes works as
> expected.
>
> I can't find anything in the latest documentation that suggests that the
> child object ids in sealed volume fstrees should be handled any
> differently, and the flags in the tree suggest that these are virtual
> object ids.
>
> Is there another layer of indirection or a different omap that I need to
> parse to link the child nodes on sealed volumes?
Unfortunately, it looks like the new documentation left out some details.
The binv_child_oid values of hashed trees are relative to the root node's OID.
So, if the root node's OID is X, when you look the child up in the OMAP, you'll
look for object "X + binv_child_oid".
The binv_child_hash fields are actually variable-sized up to the documented max.
The size of that field will match the size of the hash algorithm being used.
Also, BT_NOHEADER does not mean that the btree node objects don't have object
headers (like OBJ_NOHEADER means), but rather that the btree node headers have
the object header portion zeroed out.
HTH
--macko
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden