Thank you for the clarification, Mike! This was very helpful. On Wed, Oct 28, 2020, 17:04 Mike Mackovitch <ma...@apple.com> wrote:
> 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 (Filesystem-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/filesystem-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
