I'm strugling to recover a FAT32 partition on a 300GB drive. It looks like about 100 sectors were wiped near the beginning of the drive. The VBR is gone as are several FAT1 sectors.
I used the FAT2 sectors to recreate the missing FAT1 sectors and a spot check of FAT entries to directory entries appear accurate. All other data on the disk looks intact.
Enase's partition recovery comes close but seems to be off by 16 sectors Actual root is +16 sectors from indicated, dir ABC is +16 sectors from indicated, and file XYZ is +16 sectors from indicated. Spoke to Guidance; they weren't sure how to resolve. I may just try to recreate the VBR with a Hex editor, but I was wondering if anyone had a better method? Or maybe someone has a better idea of what's going on? Maybe someone has an Enscript where I can customize the VBR parameters?
Other useful info
Partition starting at sector 63
Partition size 625,137,282 sectors
Sectors per cluster 64
Sectors per FAT 76318
I appreciate any helpful ideas.
A little more info
The MBR is intact but may be wrong. Encase is calculating the sectors per fat as 8 sectors too many (which would explain why all files are + 16 sectors). Possibly because the size of the partition indicated in the MBR is incorrect? What I think I need is an algorithm to calculate the total sectors in a partition given a known sectors per fat. I've tried some guesses, but they haven't worked out yet. Where is Brian Carrier when you need him?
Problem Solved - but probably not the easiet way. Encase way very well be calculating FAT size correctly, but according to a Microsoft Document…
"Do not spend too much time trying to figure out why this math works. The basis for the computation is complicated; the important point is that this is how Microsoft operating systems do it, and it works. Note, however, that this math does not work perfectly. It will occasionally set a FATSz that is up to 2 sectors too large for FAT16, and occasionally up to 8 sectors too large for FAT32." [My Emphasis]
Since I tried the math myself and came up with the same as Encase, I just iterated through a few values and measured the sector offset "FAT2 ended x sectors too late", etc. After only 5 tries, I found a magic value that was about 70k sectors off from what was indicated in the MBR.
When I hit that "magic" number, Encase seemed to have frozen, but after about 3 or 4 minutes, the FATS lined up with the root and all of the files were in view.
I know this isn't much of a formula, but if you apply methodically; maybe you'll get lucky too.
Congrats…. it' was a good read also..
Thanks RJ. In case someone else runs into this rare problem, here's a little more info
The number of clusters in the partition I entered into Encase to recreate the partition was larger than the physical disk (and image); and Encase won't accept that value. But I had already restored the image onto a larger drive (It didn't have to be bigger, but it was and that proved helpful as you'll see) so that I could use a hex editor to copy the missing FAT1 sectors from FAT2 to the beginning of FAT1.
Since the new (larger) drive could accomodate a larger partition size, Encase accepted my iterative guesses until the algorithm calculated the correct FAT size. Much like a NOP Sled, I could see if my guesses were heading in the right direction, but I had no precise formula.
Sure it took me a few hours to figure all of this out, but knowing that Microsoft's "math does not work perfectly", you can now "solve" the problem in just a couple minutes; which is faster than creating a VBR from scratch. But I've been doing this for over five years now, and this is the only time I've come across this weirdness.