The block tables of a UDIF image are kept in an XML property list, placed after the data fork. The trailer gives its offset and length. Older images keep the same tables in a classic Macintosh resource fork.
The property list
The top level is a dictionary with one key, resource-fork, whose value
is a dictionary with one key for each resource type. Each type’s value is an array
of resources, as the entries of a resource fork would be. The one that matters is
blkx: one entry for each partition of the disk.
…XML header the XML declaration and DOCTYPEvaries…resource-fork a dictionary of resource typesvaries…blkx an array, one dictionary for each partitionvaries…Data amishblock table in base64, on lines of indented textvaries
A blkx entry
| Key | Type | Meaning |
|---|---|---|
Name | string | The partition’s name and map type, for example disk image (Apple_HFS : 2) |
CFName | string | The same, for tools that read it through Core Foundation; often the same text, and sometimes missing |
Attributes | string | A value in hexadecimal; 0x0050 and 0x0000 are seen in practice |
ID | string | The entry’s number, as a resource ID. In the images checked the first entry (a protective MBR or a driver descriptor map) is −1, and the rest count from 0 |
Data | data | The mish block table, in base64 |
Base64 lines are usually broken with tabs and newlines. A reader skips the white space and decodes the rest.
Other resources
Images may have other resource types beside blkx:
| Key | Holds |
|---|---|
plst | A small resource seen on most of the images checked; what it holds is not documented |
cSum, nsiz, size | Resources seen on some images; their contents are not documented |
LPic, TEXT, RTF , STR# and styl | The licence agreement a Mac shows before mounting an image, on images that have one |
The resource fork form
An image with an XML length of zero and a non-zero resource fork length in the trailer
keeps its tables in a classic Macintosh resource fork, embedded in the file at the
resource fork offset. The same blkx type then holds one resource for each
partition, its data being the mish block table directly, not base64.
A resource fork starts with a 16-byte header of four big-endian numbers: the offsets of the data and the map, and the length of each. The map’s type list gives each resource type and how many resources it has; each resource has an ID, a name and a three-byte offset to its data, which is a 4-byte length and the data.