If an HFS+ partition is ever not unmounted cleanly when the system shuts down, it is marked as unclean. OS9 and OSX do the right thing here, perform some basic checks, and mount it fine. Under Linux, it "appears" to mount fine read-write but in reality it is forced to be read-only. There is *no* workaround apart from booting into OS9 or OSX and shutting down cleanly. There is code in the HFS+ module responsible for this wacky behavior. Reproducible: Always Steps to Reproduce: 1. On a dual-booting machine, boot into OS9 or OSX. 2. Force reboot (cmd-ctrl-power) and start up in Linux. 3. Try to mount the OS9/OSX partition read-write. CHECK to make sure it succeeded, it will silently fail. Actual Results: mtab claims mounted read-write, /proc/mounts correctly specifies read-only, partition cannot be written to. Expected Results: Partition should actually have been mounted read-write.
Created attachment 119133 [details, diff] Patch to fix this behavior This patch preserves the dmesg warning recommending fsck.hfsplus but removes the unavoidable read-only mounting behavior. (I used a similar patch on an older system with critical HFS+ components. I should have submitted it back then, but I was a bad netizen...)
I'm not sure what you're asking for here, the reason why it's marking it read only is because the disk is inconsistent. If you really want to just write to the disk, you can force it on by adding -o force to your mount options. If you want to check the disk, you can emerge diskdev_cmds to get fsck.hfsplus, which can check your disk before mounting if you set it in fstab, just like any other filesystem. This kernel patch will certainly get rejected though, sorry. :(
> the reason why it's marking it read only is because the disk is inconsistent. It is not marking it read only because it's inconsistent, it's marking it read only because a single bit is set in the header that indicates that there is a microscopic possibility that it *might* be inconsistent, which is a bad thing and nothing like ext3 or reiser or any of the other filesystems in common use do. > If you really want to just write to the disk, you can force it on by adding -o force to your mount options. That doesn't do any good. It doesn't even check the force option until after it's checked the "mounted" bit. > If you want to check the disk, you can emerge diskdev_cmds to get fsck.hfsplus, > which can check your disk before mounting if you set it in fstab, just like any > other filesystem. I had fsck.hfsplus installed, and the HFS+ partition in question was in fstab. So you're saying it should have Just Worked? (It didn't.) Also, last time I hit this "issue," fsck.hfsplus had no effect and didn't set (or unset, I forget which) the necessary bit. There was no way around this at all except to mount the partition in Mac OS and then shut down cleanly before going back into Linux. To reiterate, remounting it doesn't work, -o force doesn't work, fsck.hfsplus doesn't work, and no other filesystem that I know of has anything like this behavior. This needs to be fixed, and the lack of a fix broke a system that I was maintaining. -:sigma.SB
Sorry, but you're barking up the wrong tree here. If you want it into the kernel you should send it to the relevant kernel developer. Until it gets accepted I'm afraid you'll have to apply it the kernel yourself.
