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 <[EMAIL PROTECTED]> wrote: > > 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'
