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

[Eric Dunbar]

Dank je wel voor de informatie!

I guess it's the kHFSVolumeUnmountedBit that's being cleared
improperly (or, perhaps the coders are using that "unused" bit to
avoid corrupting the HFS+ partition?... I wonder if the mystery is
addressed in the source?).

Eric.

On 11/26/05, R. Hirschfeld <ray at unipay.nl> wrote:
> > 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.)
> >
>