I backed up everything in the /mnt/sd_card directory thinking that some dataloss could occur for some reason but purposely left my microSDHC unbacked up thinking that "it won't touch that since it's external" and Samsung's and other manufacturers website even say this (that it won't be affected and not to worry etc).
Apparently I was wrong, my microSD was "undetected" and asked to be formatted after the upgrade (there goes 3-months worth of family photos). No, of course I didn't format though since I already knew what happened, somehow during the upgrade the card was corrupted. I'm sure that the card was mounted and the OS was rebooted without unmounting it and this easily causes fat32 dataloss.
So what are the options?
The most obvious thought and hope to me is that the partition table was just corrupt and my data would be easily accessible as some have said in forums, or maybe the card just wasn't being mounted by the phone. My card was corrupt and it had nothing to do with mounting as some lucky people have encountered.
The filesystem as I said was clearly corrupt, fdisk returned no partitions.
#1 Backup the current state to an image
This assumes your sdcard is plugged in as /dev/sdc, change it to whatever is correct for you.
dd if=/dev/sdc of=sdc.img; cp sdc.img sdc.img-orig
The cp command also makes a backup of the image so you can play around the with the backup and still have something to restore if you mess it up.
Run testdisk on your image:
Basically it was able to restore the partition table and either through the partition or testdisk I could restore about 2.3 gigs of data. But here's the weird part.
df -h reports about 7 gigs used on the card (which I know is correct) but the actual accessible files are about 2.3 gigs and are from when I first installed the card. It's as if the data from the weeks after is ignored/missing/inaccessible. An fsck.vfat wasn't able to help with this either.
Also all of the 2.3 gigs of pics/videos have corrupt headers and no program can view or open them.
I've tried everything and unfortunately haven't been abl to recover anything working, let alone find the other 5 gigs of missing data.
I wasn't able to recover any working data.
As mentioned above I wasn't able to recover anything unfortunately and I've tried other tools that examined the filesystem and tried to recreate missing files without any different result. My conclusion is that somehow besides corruption, some glitch caused the files to be permanently erased. I'm still keeping the original image file(s) in hope I may be able to find a solution in the future but I'm not optimistic.
In hindsight I learned a few valuable lessons here that I'll share after this.
1. NEVER use fat32 as your filesystem if possible for anything (not your phone, not your external hard drive etc..), I believe Android generally supports other journal'd filesystems like ext3 and maybe NTFS. Take the time and don't use the default fat32 or let Android format your card, do it on your computer with ext3. The reason is that in the event the card is not unmounted or the power is suddenly cut, you shouldn't lose data like fat32 will, this is the nature of fat32 being unjournaled.
2. You just never know, I should have removed the microSDHC card like my gut told me before upgrading or at least backed it up (I normally do periodic backups anyway but this is the one time I didn't and look what happened!).
samsung, galaxy, upgrade, ics, microsdhc, detected, dataloss, upgrading, solutionsi, mnt, sd_card, directory, occur, purposely, unbacked, quot, external, manufacturers, website, etc, microsd, undetected, formatted, didn, format, corrupted, mounted, os, rebooted, unmounting, partition, corrupt, accessible, forums, wasn, mounting, encountered, filesystem, fdisk, partitions, assumes, sdcard, plugged, dev, sdc, dd, img, cp, orig, restore, testdisk, gigs, df, installed, ignored, inaccessible, fsck, vfat, pics, videos, headers, ve, haven, abl, examined, recreate, corruption, glitch, permanently, erased, optimistic, hindsight, ll, android, generally, supports, filesystems, ext, ntfs, default, unmounted, shouldn, unjournaled, periodic, backups,