[hfs-user] Embedded volume..
Fri, 22 Feb 2002 17:11:05 +0000
Thats Ok, I knew what you meant.
This exact issue is discussed in the HFS+ Tech Note. Anyway,
Well HFS Wrappers are there so if you put the HFS+ disk into an old Mac,
(that doesn't support HFS+) it'll still see it, and know not to erase it. In
particular if you get a really old Mac, they support HFS in the BIOS, so need to
see a HFS disk before they attempt to boot from it.
The idea is you see the HFS disk, then either begin booting from it (and get
just enough code from the boot sector of the HFS Wrapper to load the real boot
code in the HFS+ disk inside that wrapper), or you simply see the HFS Wrapper
and don't see the HFS+ disk at all. In the latter case, the HFS Wrapper will
have a file called 'where_have_all_my_files_gone' which explains the situation.
Any attempt to erase the disk will fail to erase the Bad block file, and hence
keep the HFS+ volume intact.
The replacement of drVCSize with drEmbedSigWord, and drVBMCSize (and
drCtlSize) with drEmbedExtent, allow any system thats in the know to read the
HFS Wrappers MDB and know instantly where the HFS+ Volume is.
Its worth noting that the HFSWrapper marks the whole disk as read only, so
old Macs will never attempt to change anything (including the drVCSize and other
now replaced fields), and any system tools that check the disk will leave those
fields alone, because they were all marked as reserved anyway.
The whole point is that if you load an MDB data structure into memory, then
start treating it as such, it looks like a HFS Wrapper is supposed to. However
if you treat it as a HFS+ Volume descriptor, you'll know (since drSigWord is
still 0x4244) that is a HFS Wrapper header, not a HFS+ header, then look at
drEmbedSigWord for the HFSWrapper version info, and hence find the real HFS+
Its just a way of pleasing all of the people all of the time regardless of
their point of view. You can create a HFS+ volume without the HFSWrapper if you
like, but old macs will just erase the disk for you if they encounter it. Hence
all new Macs use HFS Wrappers.
> Oops ...sorry! the second field was meant to be drEmbedExtent... wrote that
> in a hurry!
> ----- Original Message -----
> From: "Entwicklung" <Entwicklung@WHengenIBK.de>
> To: "Simon Bazley" <firstname.lastname@example.org>
> Cc: <email@example.com>
> Sent: Friday, February 22, 2002 3:05 PM
> Subject: Re: [hfs-user] Embedded volume..
> > Hello,
> > Thanks for replying... was hoping that someone would respond!
> > 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
> > 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
> > HFS volume (?). Why would anyone want an embedded partition when all data
> > could be stored in the original HFS partition? I've just set these fields
> > 0 right now and I fail to see a situation where I (a third-party
> > developer) would ever need these.
> > Any tips?
> > Regards,
> > Nandini Hengen
> > ----- Original Message -----
> > From: "Simon Bazley" <firstname.lastname@example.org>
> > To: "Entwicklung" <email@example.com>
> > Cc: <firstname.lastname@example.org>
> > Sent: Friday, February 22, 2002 2:51 PM
> > Subject: Re: [hfs-user] Embedded volume..
> > > I'm not sure exactly what you're referring to, but heres a few pointers.
> > >
> > > The volume is the thing that you mount on your computer which provides
> > > files. It represents the single mount point which appears as a disk on
> > > your computer.
> > > The HFS Wrapper is a HFS partition consisting of a massive consecutive
> > > bad block file, which happens to be a HFS+ partition thats embedded in
> > > the HFS volume.
> > > The important difference between HFS+ and HFS is that wheras in HFS
> > > certain files (Device Drivers, Boot System Files, Allocation Bitmap)
> > > exist at various physical disk locations (sector 0, sector, sector 4
> > > etc) and the MDB only gives the location to the Catalog and Extent
> > > files. Also there are 2 different address spaces, physical (in
> > > sectors), and logical (in blocks, starting at 0, after the end of the
> > > volume bitmap, at the location described in the MDB as the start of free
> > > space). HFS+ has very little (if any) system files at fixed locations,
> > > and everything is referred to in the volume descriptor (replaces the
> > > MDB), in the way the Catalog and Extent files was before.
> > >
> > > Hope that explains everything, if not give me the names of the variable
> > > in the HFS and HFS+ volume descriptors and I'll explain what they mean.
> > >
> > > Simon
> > >
> > > Entwicklung wrote:
> > >
> > > > Hi, what exactly does the term embedded volume mean? I've noticed
> > > > that the HFS MDB has some fields related to this but the HFS+ volume
> > > > header doesn't seem to. I'm not really using these fields but I'd like
> > > > to know what they're used for in any case. So if anyone could
> > > > enlighten me I'd appreciate it. Regards,Nandini Hengen
> > >