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 files.
(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.
-Mark