workaround for problem with hfsplus driver

[R. Hirschfeld]

A situation arose today that took me a while to resolve and I thought
I'd pass along the resolution in order to save some head-scratching of
others who may encounter the same problem.

If YDL crashes while an hfsplus filesystem is mounted it subsequently
refuses to mount that filesystem read/write.  From dmesg:

HFS+-fs warning: Filesystem was not cleanly unmounted, running fsck.hfsplus is recommended.  mounting read-only.

There is no fsck.hfsplus that I can find, running hpfsck from the
hfsplusutils package does not fix the problem (I hope it didn't mess
up my filesystem--it did report making some changes), and running Disk
First Aid under MacOS also doesn't help.

Apparently none of these things resets the consistency bits in the
filesystem appropriately, so it appears that you're never again able
to write to it under YDL!

Fortunately I was finally able to do so as follows (substitute the
actual device name of your hfs+ partition for /dev/hda13):

hpmount /dev/hda13
hpumount

and then I was able to mount the filesystem normally and write to it
again under YDL.  The utilities /usr/bin/hpmount and /usr/bin/hpumount
are from the hfsplusutils package.

Hope this helps someone,
Ray

P.S. One thing I didn't try was mounting the filesystem as a non-boot
volume under MacOS.  That *might* have made a difference.  There are
two complementary consistency bits and I suspect the problem stems
from the kernel hfsplus driver checking both while MacOS only resets
one of them.  Here are two relevant notes from Apple's HFS Plus spec:

Note:
The existence of two volume consistency bits (kHFSVolumeUnmountedBit
and kHFSBootVolumeInconsistentBit) deserves an explanation. Macintosh
ROMs check the consistency of a boot volume if kHFSVolumeUnmountedBit
is clear. The ROM-based check is very slow, annoyingly so. This
checking code was significantly optimized in Mac OS 7.6. To prevent
the ROM check from being used, Mac OS 7.6 (and higher) leaves the
original consistency check bit (kHFSVolumeUnmountedBit) set at all
times. Instead, an alternative flag (kHFSBootVolumeInconsistentBit) is
used to signal that the disk needs a consistency check.

Note:
For the boot volume, the kHFSBootVolumeInconsistentBit should be used
as described but kHFSVolumeUnmountedBit should remain set; for all
other volumes, use the kHFSVolumeUnmountedBit as described but keep
the kHFSBootVolumeInconsistentBit clear. This is an optimization that
prevents the Mac OS ROM from doing a very slow consistency check when
the boot volume is mounted since it only checks
kHFSVolumeUnmountedBit, and won't do a consistency check; later on,
the File Manager will see the kHFSBootVolumeInconsistentBit set and do
a better, faster consistency check. (It would be OK to always use both
bits at the expense of a slower Mac OS boot.)