[ydl-gen] HFS+ mount is read only -- how to make RW? (YDL 4.0.1)

[R. Hirschfeld]

> Date: Fri, 25 Nov 2005 10:07:41 -0500
> From: Eric Dunbar <eric.dunbar at gmail.com>

> Now, it seems that somehow my HFS+ partition has been "damaged" again,
> and I can't write to it even though mount says it's rw:
> 
> Does anyone know what the problem is and/or how to fix it (i.e. make
> it read-write again)?

Here's a message I sent to the list a year and a half ago that I think
addresses your problem.  I've used this technique successfuly several
times since then; it works because hpmount resets the filesystem
consisitency bits.

Ray


> Date: Sat, 31 Jul 2004 15:50:10 +0200
> From: "R. Hirschfeld" <ray at unipay.nl>
> To: yellowdog-general at lists.terrasoftsolutions.com
> Subject: workaround for problem with hfsplus driver
> Reply-to: ray at unipay.nl
> 
> 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.)
>