Hard Drive Partition Space Lost

It's now unallocated space at the end of the partition map. And, because you used Boot Camp originally there's no telling how badly your partition map is now that you let Windows shrink the partition.

At this point I can't give you a definitive answer. You cannot remove it with Boot Camp Assistant anymore. Windows disk management tool does not understand the Mac's GPT partition structure, so I cannot begin to tell you what you can do at this point. Were I dealing with it directly I would just be doing trial and error (and hoping you had backups.)

I would assume that you have indeed shrunk the original partition down to 123 GBs, but I don't know if the other 100 GBs has been deallocated and it's unlikely that OS X' Disk Utility will now be able to handle the drive properly. It's likely that you still have the original 232 GB partition and merely shrunk it but did not release the space to make another partition.

In any event you cannot simply shrink a partition and have the space allocated magically to some other partition on the drive unless you are using specialized software such as the iPartition 3.4.1 that can actually move partitions anywhere.

post the results of the following command typed into the Mac OS X Terminal application:

sudo gpt -r show /dev/disk0

Only windows (generally) will see the two partitions where you had Windows only.

Adding a partition beyond where Windows goes can be done.

The way to 'give' Mac OS space though is through CampTune - and maybe iPartition (never used it so cannot comment but some people use it - seems to depend on the expertise of the user and their planning).

Actually it's just a matter of deleting the superfluous Windows partitions using GPT fdisk (gdisk), and the resizing the Mac OS HFS+ volume using 'diskutil resizevolume <dev> <size>'.

First round command to find the maximum size possible is:

diskutil resizevolume /dev/diskXsY limits

then use

diskutil resizevolume /dev/diskXsY <size>

where <size> is in G or T, matching the maximum size possible returned by the first command. Both commands can be used while the computer is booted from the target volume, although it may be best to reboot after altering the partition map, before resizing.

You may but I do not know the side effects of killing the GPT. And there is a backup GPT area.

I'm not suggesting killing the whole GPT, but editing it just to remove his extra Window(s) partitions such that he has unallocated/free space instead.

GPT fdisk (gdisk) is expressly designed for creating, manipulating, and fixing GPTs. This includes verifying the validity of the primary and secondary tables using the checksum in the two headers. And resolving any disconnect/ambiguity between the two tables. By default, it will also create a new protective MBR entry.

Removing individual entries from the GPT is a piece of cake. It's a little baffling why Disk Utility won't let us do this when volumes in those partitions aren't presently mounted. *shrug* but that's the way it has always been it seems. We've always been told we have to completely repartition from scratch and reload all our software and it's just totally false.

sudo is privilege escalation, required to run the gpt program on an active disk. The -r flag is read only so it is not going to lead to data loss. 'show' is going to display the GPT partition table. And /dev/disk0 is presumably your internal hard drive, the drive in question you are asking about.

I am not able to see the tiff you attached.

And what do you get for:

sudo fdisk /dev/disk0

Definitely do not add a -r to the above command. Type it exactly as I did.

No. This command makes no modifications, it will only read and display the MBR table entries. You can 'man fdisk' to read all about the command if you want. But -r does something quite different with this command compared to the gpt command.