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 folders).
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...
Regards, Nandini