[hfs-user] Embedded volume..
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
> know though I don't see the purpose of having a HFS+ partition embedded
> in a
> HFS volume (?).
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
> 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.