[hfs-user] Embedded volume..

Mark Day mday@apple.com
Fri, 22 Feb 2002 08:22:03 -0800

On Friday, February 22, 2002, at 06:05  AM, Entwicklung wrote:

>         I was referring to the fields:
>   UInt16 drEmbedSigWord ;//embedded volume signature - formerly drVCSize
> and HFSExtentDescriptor drEmbedSigWord ;//embedded volume location and
> size - formerly drVBMCSize and drCtlCSize

These fields are used when you have an HFS Plus volume with an HFS 
wrapper.  These fields describe the size and location of the HFS Plus 
volume that is embedded inside the HFS wrapper.  The drEmbedSigWord 
tells you that there is an embedded HFS Plus volume, and that the extent 
descriptor is valid.

> I think what you mentioned about Wrappers is relevant to what I wanted 
> to
> know though I don't see the purpose of having a HFS+ partition embedded 
> in a
> HFS volume (?).

See <http://developer.apple.com/technotes/tn/tn1150.html#HFSWrapper>

It says:

An HFS Plus volume may be contained within an HFS volume in a way that 
makes the volume look like an HFS volume to systems without HFS Plus 
support. This has two important advantages:

1.	It allows a computer with HFS (but no HFS Plus) support in ROM to 
start up from an HFS Plus volume. When creating the wrapper, Mac OS 
includes a System file containing the minimum code to locate and mount 
the embedded HFS Plus volume and continue booting from its System file.
2.	It improves the user experience when an HFS Plus volume is inserted 
in a computer that has HFS support but no HFS Plus support. On such a 
computer, the HFS wrapper will be mounted as a volume, which prevents 
error dialogs that might confuse the user into thinking the volume is 
empty, damaged, or unreadable. The HFS wrapper may also contain a Read 
Me document to explain the steps the user should take to access their 

(That is, it greatly eased the transition from HFS to HFS Plus for 
Macintosh users.  Note that HFS wrappers aren't required to boot Mac OS 
X, so wrappers are becoming less important, and may stop being used at 
some point in the future.)

>  Why would anyone want an embedded partition when all data
> could be stored in the original HFS partition?

With large volumes, you might not be able to store all the data on a 
pure HFS volume because the allocation block size is too large.  The 
most important reason for HFS Plus was to increase the number of 
allocation blocks, so each allocation block could be smaller, and 
allowing you to put more files on a volume.

For example, the HFS Plus volume I'm booted from right now has about 
170,000 files on it.  Since HFS can have at most 64K allocation blocks, 
there's no way I could put that many files on an HFS volume -- no matter 
how big it is.

Since the Mac OS ROM only knows how to boot from HFS volumes, having an 
embedded HFS Plus volume means I can boot from it directly, rather than 
having to partition my disk with an HFS boot volume and an HFS Plus 
volume for all my data.

>  I've just set these fields to
> 0 right now and I fail to see a situation where I (a third-party 
> HFS-volume
> developer) would ever need these.
>  Any tips?

If you only want to produce pure HFS volumes (with no embedded HFS Plus 
volume), setting the fields to zero is correct.