Living With Apple's MacBook: Partition Corruption (and Resurrection) And Other Updates

Two-plus weeks into life with an Apple MacBook running Windows XP Professional (along with, of course, OS 10.4), the inevitable glitches are becoming more numerous and noticeable, although to put what follows in perspective, I’m still very pleased with my new system. If you’ve missed some of my past posts in this series, hit the links below before proceeding with this writeup:

• Apple: Writing the (Mac)Book on Laptop Design
• Day 1
• Circumventing Various Shortcomings
• The Two-O/S Two-Step
• Resurrecting The Cellular Tethers
• Battery Brains: Beware The Drains

OS X has built-in read-write support for the FAT and FAT32 formats that originated in DOS and Windows and have now become pervasive (albeit with unclear patent infringement implications) in digital cameras, USB flash drives and other applications. OS X also includes support for the newer NTFS Windows format, albeit in a read-only fashion (which you can beef up via some Google-sponsored ingenuity). Conversely, Windows XP by default doesn’t support OS X’s HFS+ format. That’s where Mediafour’s MacDrive comes in. After installing MacDrive v7 and rebooting, I had full read/write access (as drive F:) to the MacBook HDD’s HFS+ partition housing OS 10.4…

…at least until yesterday, when I reconfigured MacDrive for read-only HFS+ access. That’s because sometime between Sunday morning and Monday morning, my HFS+ partition became corrupted, leaving me unable to boot OS X (but ironically still able to run Windows on this Apple-branded hardware!). It could have been a coincidental fluke, or an unforeseen downside of my two-O/S two-step described above…or it could have been caused by one of the many Windows programs I installed over that 24-hour timeframe, unintentionally writing something unintelligible-to-OS X to the "F: drive".

From now on, if I need to write something from Windows to the HFS+ partition, I’ll boot OS X and copy the desired files from the NTFS partition instead. More time consuming, yes, but also safer. Similarly, going forward I doubt I’ll run Parallels Desktop for Mac much (if at all) using my Boot Camp Windows XP build, since Parallels is (via its built-in MacFUSE support) able to alter the contents of the NTFS partition. A few releases ago, a Parallels Tools update-gone-awry resulted in a very scary CHKDSK repair session the next time I booted Windows. My Outlook database and other NTFS partition data is way too valuable (regardless of the fact that I periodically back it up) to expose it to risky software configurations. I generally avoid beta software like the plague, for the same reason.

So how’d I recover my OS X-and-applications build? OS X’s built-in Disk Utility wasn’t able to repair the partition; ironically, in fact, it seemed to make the problem worse (for those of you who don’t already realize this, you can attempt repair on your boot HDD partition by inserting disc 1 of the CD set that came with your Mac, reboot the system while holding down the ‘c’ key to boot off the CD instead of the HDD, then select Disk Utility from the resultant diagnostics screen). Prior to running Disk Utility, I was still able to ’see’ the HFS+ partition from Windows via MacDrive, and I took advantage of that fact to copy some particularly valuable files over to the NTFS partition. After running Disk Utility, MacDrive reported that the HFS+ partition was corrupt and flat-out gave up; MacDrive’s built-in repair utility also was of no help at this point (it suggested a reformat, which I declined).

I had a copy of Prosoft Engineering’s Drive Genius on-hand, but the MacBook refused to boot from the CD. Since it was Labour Day, I suspected I wouldn’t be able to quickly get hold of anyone in technical support to resolve the boot problem. Then I remembered that, by virtue of my AppleCare extended warranty plan, I had access to Micromat’s TechTool Deluxe. I downloaded the image file and burned it to DVD on my dual G5 Power Mac, then booted the MacBook with the disc and ran through the diagnostics. As expected, the volume structure test found ‘Catalog B-Tree’ errors, but the repair attempt was unsuccessful. However, on a hunch, I ran the test-and-repair again…and found that the ‘reported’ and ‘repaired’ volume attributes were different this time. The second repair attempt was also unsuccessful…as was the third…and the fourth…but the fifth iteration did the trick. Phew!

Continue reading with ‘Living With Apple’s MacBook: Various Video Travails‘…