[hfs-user] Wrapper and Readme

Entwicklung entwicklung@whengenibk.de
Fri, 3 May 2002 18:56:21 +0200


> Remember that the alternate MDB or alternate Volume Header starts 1024
bytes from the end of the volume.  So, on a CD with 2048-byte physical
sectors, it would start in the middle of the last physical sector.  In the
case of a wrapped HFS Plus volume, the alternate MDB is 1024 bytes from the
end of the volume, and the alternate Volume Header is 1024 bytes from the
end of the embedded part of the volume.

Yes, that's the way it is in my implementation too...

> The last 512 bytes of the volume (and embedded volume) are reserved for
uses outside the filesystem.  Apple's manufacturing process uses the space
for various things, without having to disturb the actual volume contents.

I've just set the last 512Bytes to zero - reserved.

> I don't know much about the low-level data organization on CDs, but I
would think that the driver shouldn't include runout blocks as part of the
data (i.e. part of the logical device or partition).  Might you actually be
writing data past the end of your volume?

The runout blocks are just present after the data-part and get appended by
the driver responsible for writing out the data - starting off at the point
where the data ends. The logical part or partition ends 1024Bytes after the
start of the alternate volume header as you said.

> If you're working with disk images, you could try truncating the image to
1024 bytes past the start of the alternate MDB (or alternate Volume Header
for unwrapped HFS Plus volumes).  But you still ought to figure out why
there is extra data past the logical end of your volume (or why you aren't
putting the alternate MDB/VH in the correct spot).

As mentioned - these extra blocks are not data but Disk First Aid apparently
mistakes them to be so since it starts checking from the end....Could it be
that I'm making a mistake in my allocation bitmap (in the volume header)?
.... if my HFS-volume has n sectors(2kB) including the 2kB blocks containing
the volume header and alternate volume header, with block size =512Bytes I
would have to account for (n-1)*4 if I'm marking all blocks as allocated,
right ? Or should it be (n-2)*4 ?

> Disk First Aid tries to use the alternate MDB/VH to identify the volume
and find the various structures.  The idea is that if the first few blocks
of the volume have been overwritten, Disk First Aid can find and fix the
volume using the alternate structures, and write corrected information back
out to the main MDB/VH.  Current versions of DFA should try to find the main
MDB/VH if it can't find any alternate.
Which are the versions which do this ?