Unallocated space not appearing is not really a problem; many programs, including gdisk
and diskutil
, display only partitions, not unallocated space. Tools like GParted and cgdisk
explicitly show unallocated space (although I think even GParted omits unallocated space below a certain size).
There are two ways to define partition order: The order on the disk of the partitions themselves and the order in which pointers to the partition exist in the partition table. It's least confusing if these two orders match, but there's nothing in GPT (or MBR primary partitions) to enforce this. Thus, out-of-order partitions are common and do not necessarily signify a problem. Don't worry about that detail.
Thus, the only real problem you're reporting is that your HFS+ volume has become inaccessible. This might be a partition table problem, but it's more likely to be a filesystem problem. Unfortunately, without detailed before-and-after information on partition start points, I can't differentiate the two possibilities. The safest way to proceed is:
- Do a low-level backup of the partition with
dd
in either OS X or Linux, as insudo dd if=/dev/disk2s3 of=/path/to/lots/of/space/disk2s3-backup.img
. This will preserve the data in the partition in case the next step makes things worse, which is a real possibility. You should also back up the partition table as it is now by using theb
option ongdisk
's main menu. - Use OS X's Disk Utility to repair the partition. The GUI tool should be able to do this. I'm less familiar with the OS X command-line tools to do this, but in Linux it would be
fsck
, and it might be the same in OS X. - If this doesn't work, restore the backup you made in step #1 by reversing the
if=
andof=
options.
If that doesn't work, I do have another few suggestions:
- You could delete the errant partition and try using TestDisk or something similar to recover it. The idea here is that whatever you used to modify your partitions might have adjusted the start point of your HFS+ partition, which would render it inaccessible. TestDisk scans for filesystems and creates new partition table entries for them, which should fix that problem. This isn't a sure thing, though.
- Re-create the partition and restore its files from a backup.
- If that fails, restore the original partition (by re-creating it using the exact start and end points it has now or by restoring the
gdisk
partition table backup) and use PhotoRec, or a similar tool, to recover the partition's contents on a file-by-file basis. This will be much more tedious than restoring files from a backup, and you're unlikely to recover everything, but with any luck you'll be able to recover most of the files.
It might be helpful to know what tool you used to resize the NTFS partition and create a new one. Although I don't know of any bugs in common utilities that would produce this exact symptom, I certainly trust some partitioning tools more than others. (The standard Windows utilities are very buggy with extended/logical partitions on MBR disks, for instance -- but yours is a GPT disk, so that's not really an issue.)
EDIT:
I just noticed something about your description: What should be an HFS+ volume is marked as being of type "Microsoft Basic Data" by diskutil
. That's Just Plain Wrong. It's easily fixed with gdisk
:
- Launch
gdisk
on the disk. - Type
p
to view the partition table and positively identify the partition that can't be accessed. I expect it to be partition 3, but it's best to be sure. - Type
t
to change the type code. You'll be asked for a partition number. - Type
3
(or whatever the appropriate number is, as just identified). - When prompted, enter a type code of
AF00
. - Type
w
to save your changes. (You'll be asked for verification.)
This should fix the problem. (If you do it from OS X, you may need to reboot.) There's a chance that you'll need to enter AF05
rather than AF00
as the type code, so if it doesn't work, try repeating that process, but with that change.
Other tools can probably fix it, too, but I'm not familiar with the procedures, offhand. (Maybe removing the "msftdata flag" in parted
or GParted would do it....)