Basically.

A FAT32 table is nothing but a "sequence of groups of 4 bytes, each pointing to the next group in a chain, and each representing a cluster".

Each sector of 512 bytes contains thus 128 of such "groups"

A valid bootsector contains (related strictly to the filesystem) 6 pieces of info:

- how many sectors are before the beginning of the volume <-this is the same info that you can get from the MBR, i.e. 63
- how many sectors are reserved <- this are the very beginning of the volume and correspond to the bootsector itself, plus "auxiliary sectors", like the backup of the bootsector, code (in the case of a bootable volume) exceeding the bootsector, etc.
- the cluster size <- number of sectors that are indexed "together" i.e. 64
- how many FAT tables there are <- normally 2, in some rare cases 1
- how many sectors are "dedicated" to the FAT table <-these need to be "enough" to index the whole amount of clusters in the volume
- how many sectors are in the whole volume <- i.e. "size of the volume", this is the same info that you can get from the MBR, i.e. 1953520002

#1 and #6 are not a problem (as we got them from the MBR)

#2 is a guess, but a - allow me - very educated one, as when a volume is "large enough", 32 reserved sectors are common AND we found what has the aspect of a second sector of a FAT on sector 96.

#3 is also a guess, but also a very educated one

#4 is one of the problems, as a "normal" Windows Format won't allow to create a FAT32 volume larger than a relatively small size and while almost all third party programs also use 2 FATs, it is possible that a "custom" programs creates just one

#5 is the biggest problem

You have a volume that has a sector size of 1953520002, of these 32 are reserved, so you have left 1953519970 sectors.

Of these we know that a (second) part is addressed in clusters of 64 sectors, and that before them there are a number of sectors, each addressing 128 clusters, times 2, and that these sectors must be enough to address each of the clusters in the second part.

So you have an equation *like*:

2x+y=1953519970

Where y should be in theory a multiple of 64 and x=y/128

The problem is with the "rounding".

I resolved (actually simulated your disk using a tool I have) the equation as:

2*238409+1953043152=1953519970

the 238409 sectors are enough to index 238409*128=30516352 clusters and 30516352*64=1953046528 (more than the 1953043152 remaining), BUT 1953043152 is not exactly divisible by 64.

On the other hand, with 238048 sectors I would have not enough "space" i.e.:

2*238408+1953043154=1953519970 238408*128*64=1953038336 (LESS than the remaining 1953043154 sectors).

BUT there is no actual "law" preventing me from allocating a slightly larger amount of sectors for the FATs, and use not *all* of them.

In other words, I could decide to solve the equation as:

2*238417+ 1953043136=1953519970

and in this case I would have 1953043136 that is perfectly divisible by 64 (and I would simply have a few sectors of the FAT tables that will be never used)

Different formatting programs may use one or the other "strategy" or use a different "rounding" algorithm.

I hope that the above is clear enough, it's a bit complex, and it is not easy to "compact" this kind of info in a forum post.

Please try posting:

- the sector 238503
- some 100 sectors starting from 238895 (or from the first sector after 238895 which is NOT empty)
- some 100 sectors starting from 238895-238409=486 (or from the first sector after 238895 which is NOT empty - 238409)

Maybe I can detect the "increasing number" pattern I was early referring to and be sure about the "sync" of the 2 tables.

I am still believing that there were originally 2 FAT tables, it is possible that just like the area from the bootsector to the first sector of the first FAT was wiped (or defective) a number of sectors from the second table were also in the same condition.

If there was only 1 FAT, the sectors that you scanned and found 00's, around 238505 and up to 238895 would belong to the first file or directory on the volume,

There is another possibility, which is that is possible that the cluster size was, instead of 64 sectors, 128 (and thus the FAT size would be halved) but it would be "non-standard", compare with:

http://support.micro...kb/140365/en-us

jaclaz