No subject

I assume it is derived from some image
attributes like volume id.


> [bug] 570187
> To start dealing with that properly, getting hfsutils
> to export libhfs library would be the way to go, as also discussed on irc.
> [...]
> * libhfs is exported at some point, so it could be re-used with libisofs 
> and/or others interested parties.

I understand that mkisofs lets HFS and ISO 9660
coexist in the same session on media. That would
mean there are two "superblocks" and two trees
with file names and file attributes.
A similar relation as with ISO 9660 and Joliet.

A libhfs that is usable by libisofs would have
to provide
- The "superblock" plus specs where to place it
  in the image data stream.
  "superblock" means a block interval that is
  embedded in the image stream and allows to find
  the root of a file tree. Typically it has to be
  stored at or near a particular address.  
- A single contiguous interval of blocks that
  represents the HFS directory tree and all
  attributes except data file contents.
It could get as input a description of the tree
of all file objects which shall show up in HFS.

There would be two passes. The first one 
determines the sizes of both block intervals.
The second one produces them as data bytes.
The size prediction has to be made without
knowing any final block addresses.
libisofs prescribes the exact start block
addresses of both intervals at the second pass.


Data file content is stored in block intervals
named "extents". These extents may be referred
freely by the various trees of an image.


Have a nice day :)

Thomas