The good news is that the data is still there and that doesn't change (unless you explicitly do something). If the data is still there, it can be recovered.
My approach would be to boot into a rescue disk (there are many options, one such thing would be the tell-tale SystemRescueCD. Then use parted (or gparted if you don't like command line) and rm the newly created partition there. That will leave you with 3 partition slots, one being free so you can re-create the lost one. Now run testdisk and hope for the best.
In the best case, pressing "Simple scan" will bring up both the just-deleted new partition and the one you want to recover within one second. In the not-so-good case, you will need to do a deep scan, which can take a while.
If testdisk, against all odds, doesn't find the partition, still all is not lost.
The partition was the last one, and it was located at the end of the disk, and of course it still is. There's no way it could have moved or gone away. As the end of E: is known, there's not a lot of guessing where formerly-F can be found (well there's possibly alignment to consider but that's no biggie, most likely you've used the default anyway, and almost certainly the partition tool will get it right anyway).
So, firing up any partition tool (even fdisk would do, but why not use parted if we have it!) and creating a new partition from the beginning of unallocated space at the end to "end of disk" (which pretty much every tool can do automatically) will do the trick. Only important thing to look out is to create the partition but not to format it, which some tools/commands may do automatically for convenience. Obviously, formatting or creating a file system will destroy your data, which is not what you want.
For parted the correct command for that would be mkpart (see documentation).
If anything short of accidentially formatting or the disk mysteriously exploding goes wrong, you can still always remove the partition and re-create it again. No sweat. The data in the partition is not affected, you're only tampering with the "container".
A more correct and safer approach would be to first create a mirror backup of the complete disk, and then perform the above. Though, seeing as actually not much can go wrong, I would personally be too lazy for that. If you are about to install CentOS, this suggests you're reasonably Linux-savy, so you might as well dd the disk (part of it) to an image, and work on the image instead. That, too, is safer.
Or, well, just go the real men road, which isn't the recommended way, but much faster and will work fine either way. It just depends on how vitally important that data is, I guess. If you aren't going to die in case the 0.01% that can go wrong do go wrong, well... you know.
Once the partition is restored, copy all files to another disk (preferrably two disks), then delete the partition and let parted move the D: and E: partitions further up so the hole from shrinking C: disappears. Lastly, create an extended partition filling all available space, and then two secondary partitions inside that one, of which one will finally hold CentOS and the other will hold the once-and-future drive F: (to which you then have to copy files again).
..
