Fw: [hfs-user] Problems with HFS+ empty volume...

Entwicklung entwicklung@whengenibk.de
Sat, 6 Apr 2002 14:50:05 +0200

Hello Mark,

> myVolHeader.lastMountedVersion=kHFSPlusMountVersion; //
> implementation version which last mounted volume
You should pick some other constant unique to your implementation.  That
way, if a bug is found in your implementation, other implementations can
check this version to correct for the bug.

In my case I've reset kHFSPlusMountVersion to my own unique creator-code
registered with Apple (it doesn't hold '8.10'  in my case)

> myVolHeader.folderCount=0; // number of directories in volume
That may be wrong.  I can't remember whether the folder count includes
the root directory.

The HFS+ TN says that it doesn't include the root folder.

> myVolHeader.nextCatalogID=0x00000000; // next unused catalog
> node ID
That number should be at least 16 (the minimum ID for ordinary files and

In case of HFS I just played around with these values and set this field to
0. This didn't affect readability in any way and my volume is a read-only
medium so no further CNID's will be assigned. This was why I've set it to 0
for HFS+ too... maybe some extra check is being made in case of HFS+ so I'll
change this to 16.

> myVolHeader.encodingsBitmap[0]=0x00000000; // which encodings
> have been used on this volume
> myVolHeader.encodingsBitmap[1]=0x00000000;
You should probably set at least bit 0 of the first field.  That
corresponds to the MacRoman encoding, which is the fallback when other
encodings don't work.

OK.. I'll do that

In general, if you're mastering CDs, the physical sector size will be
2048 bytes per sector.  You might as well make the allocation block size
and clump sizes 2048 as well.  That way, one sector is one block, and
the math is a little easier.  On Mac OS X, performance may be slightly
better if the allocation block size is 4096 (the same as its VM page
size); of course you'd only do this if you can fit all of your data in
4KB allocation blocks.

It's true that the math is a little easier but making the allocation block
bigger would not
particulary help in space-saving, would it ? In case of a CD of 650MB there
isn't much of space-saving in case of HFS+ anyway but after reading the
Specs and browsing a number of websites I came to the conclusion that my
allocation block size should be 'as small as possible and as large as
necessary'. Do correct me if I'm wrong..... In case of HFS I don't have have
a choice but for HFS+ it shouldn't be a problem setting the block-size to
512 even for images greater in size than 32MB, should it ?
I thought that was the major improvement of HFS+ over HFS.

> The only problem is that I don't have any utilities to create
> sample HFS+ images which I can cross-check my image with.... Disk Copy
> on my iMac with MacOS 9 creates only HFS-Volumes by default
In Mac OS 9, use Disk Copy to create a read/write disk image that is at
least 32MB.  That is the minimum size volume that Mac OS 9 will format
as HFS Plus (though it should recognize smaller volumes).

I just tried this out ... It works fine for volumes >32MB. Thanks !
Btw. yesterday I also came across a software MacOpener 2000 which creates
HFS+ images. After a large no. of searches this was practically the only
cross-platform tool I came across which can supposedly read and write HFS+
volumes (not freeware however). I would have probably considered buying it
if I hadn't got this bit of info from you.... but maybe someone else on the
list can make use of it after all...