> Date: Fri, 25 Nov 2005 10:07:41 -0500 > From: Eric Dunbar <[EMAIL PROTECTED]>
> 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" <[EMAIL PROTECTED]> > To: [email protected] > Subject: workaround for problem with hfsplus driver > Reply-to: [EMAIL PROTECTED] > > 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.) > _______________________________________________ yellowdog-general mailing list [email protected] http://lists.terrasoftsolutions.com/mailman/listinfo/yellowdog-general HINT: to Google archives, try '<keywords> site:terrasoftsolutions.com'
