MediaFour‘s MacDrive (7.2.6) keeps screwing up the GPT on my external GPT-formatted drive. It has one HFS+ partition and one 200 MB EFI system partition, and when I boot my iMac into Windows (Vista SP1 x86), mount the drive, and then boot back into Mac OS X (10.5), I usually find that OS X won’t recognize the HFS+ volume any more. The characteristic error is an ignore/eject/format unrecognized dialog after OS X login, and “invalid BS_jmpBoot in boot block: 000000″ from Disk Utility when trying to repair it.

It seems that the GUID for the HFS+ volume is changed from {48465300-0000-11AA-AA11-00306543ECAC} (HFS+) to {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7} (“Microsoft Basic Data”). Windows doesn’t have any trouble mounting it as long as MacDrive is installed, it’s OS X that has the problem. I was able to fix the GPT by changing the GUID back to what it should be, at which point the drive was recognized by OS X, and found that the actual HFS+ file system was unharmed. I wrote most of a GPT editor in the process, and if Mediafour doesn’t fix MacDrive soon, I may end up turning it into a one-click GPT fixer.

***

update:

Here’s the tool I used to fix my own disk: gpt_surgeon.py

It’ll need Python 2.5 or higher, and has only been tried in OS X on my own machine. Run it with no arguments or look at the code for a usage statement. The repair process goes like this:

First, list the partitions on your disk to figure out which one needs to be relabeled with the right filesystem type. If you don’t know what your disk device path is, go look in Disk Utility or System Profiler or run diskutil(8) with its list option. The path for my external disk is /dev/disk1.

$ ./gpt_surgeon.py list /dev/disk1

Read MBR and GPT from /dev/disk1.
partition 0:
     type: EFI System
     name: u'EFI System Partition'
    flags: 0x00000000
partition 1:
     type: Microsoft Basic Data
     name: u'Untitled'
    flags: 0x00000000

Note the partition that says “Microsoft Basic Data”. Assuming that you had a single non-system partition on the disk, and that the partition was HFS+ before MacDrive got to it, this is probably that partition. In my case, it’s partition 1. Remember the number; you’ll need it in the next step.

If you have multiple data partitions on the disk, especially if one of them is actually a Windows data partition, you should use something like disktype to check what filesystems are present in each partition, so that you don’t accidentally relabel the wrong one.

If you have any other partitions from this disk mounted, unmount them now.

You’ll need to run with sudo to get the privileges necessary to actually repair the GPT on disk.

$ sudo ./gpt_surgeon.py repair /dev/disk1 1

Read MBR and GPT from /dev/disk1.
Changing type of partition #1 on /dev/disk1 to HFS+...
    Opened /dev/disk1 for writing.
    Wrote MBR.
    Wrote GPT header.
    Wrote GPT entries.
    Closed /dev/disk1.
Done.

And this is what the disk’s GPT should look like afterwards. Your HFS+ partition should be mountable now.

$ ./gpt_surgeon.py list /dev/disk1

Read MBR and GPT from /dev/disk1.
partition 0:
     type: EFI System
     name: u'EFI System Partition'
    flags: 0x00000000
partition 1:
     type: Apple HFS+
     name: u'Untitled'
    flags: 0x00000000

***

second update: commenter James let me know that Christophe Grenier‘s TestDisk utility can also be used to fix this problem.

***

third update: here’s a video walkthrough of the process. For people who have Flash turned off for some reason, please see the QuickTime version of the walkthrough.

***

last update: gpt-surgeon is opening up! Thanks to all who submitted usage reports, suggestions, failure data, and proposed patches. I hope you’ll find future versions at least as useful.Comments have been turned off for this post; all questions, comments, suggestions, and support requests about gpt-surgeon must be submitted through the gpt-surgeon LaunchPad siteand should be accompanied with disktype reports.