Error in fatgen103
Mike Gonta
to calculate the number of sectors in a FAT32 File Allocation Table.
Even though the document is over 10 years old it's still the most current.
http://board.flatassembler.net/topic.php?p=127385
Mike Gonta
look and see - many look but few see
Rod Pemberton
news:imopci$rgd$1...@speranza.aioe.org...
> There is an error in the FAT Volume Initialization algorithm (on page 21)
> to calculate the number of sectors in a FAT32 File Allocation Table.
> Even though the document is over 10 years old it's still the most current.
> http://board.flatassembler.net/topic.php?p=127385
>
>
Was this mentioned a while back ... ?
There are two other documents you may want to look at.
A)
"In its document at [...]fatgen103.pdf, Microsoft proposes a much simpler
formula. However, this formula is both wrong (i.e. occasionally it produces
a smaller FAT than is needed for the clusters on disk), less generic (only
works for sector sizes equal to 512), and less efficient (in case of FAT32,
it may waste up to 8 sectors!)"
"How mformat-3.9.9 calculates needed FAT size" by Alain Knaff
http://www.gnu.org/software/mtools/manual/fat_size_calculation.pdf
B)
ECMA-107 covers FAT12 and FAT16, but not FAT32. So, I'd guess that it
would not have that calculation, although 10.3 pg 26 does present
an algorithm for SF "Sectors per Fat" which I think is the field BPB_FATSz16
in
fatgen103. FYI, ISTM that ECMA-107 calls the BPB the "FDC Descriptor".
There is also a calculation for SSA "Size of System Area" in 6.3.4 pg 19.
Annex B indicates SF can be a value of 2, 3, 7, 8, 14 or 41 as defined by
other ECMA standards.
(unstated) is ECMA-66 5 1/4" SS/SD floppy
2 is ECMA-70 5 1/4" DS/DD floppy
3 is ECMA-78 5 1/4" DS/QD floppy
7 is ECMA-99 5 1/4" DS/HD floppy
3 is ECMA-100 3 1/2" DS/DD floppy
14 is ECMA-125 3 1/2" DS/HD floppy
14 is ECMA-147 3 1/2" DS/ED floppy
8 is ISO/IEC 13422 10MB
41 is ECMA-207 21MB
I couldn't locate info on what those last two drives are. ECMA-107 doesn't
mention ECMA-66 either, i.e., no SF value. Available ECMA standards are
here:
http://www.ecma-international.org/publications/standards/Standard.htm
I don't see the ECMA standards for 5 1/4" drives, but 3 1/2" drive standards
are there.
Well, it seems you can get the old 5 1/4" standards here, except ECMA-99.
http://www.ecma-international.org/publications/files/ECMA-ST-WITHDRAWN/
That's odd, I apparently got 99 from them in '08... It's gone missing.
Rod Pemberton
s_dub...@yahoo.com
wrote:
> There is an error in the FAT Volume Initialization algorithm (on page 21)
> to calculate the number of sectors in a FAT32 File Allocation Table.
I guess you'll have to spell out the error. The algorithm covers Fat
12|16, and Fat 32, perhaps that is why it seems twisted. After
reviewing your link, and Rod's links, what I see is..
From: fatgen103.pdf
staff.washington.edu/dittrich/misc/fatgen103.pdf
--------
Page 21
--------
"""
RootDirSectors = ((BPB_RootEntCnt * 32) + (BPB_BytsPerSec – 1)) /
BPB_BytsPerSec;
TmpVal1 = DskSize – (BPB_ResvdSecCnt + RootDirSectors);
TmpVal2 = (256 * BPB_SecPerClus) + BPB_NumFATs;
If(FATType == FAT32)
TmpVal2 = TmpVal2 / 2;
FATSz = (TMPVal1 + (TmpVal2 – 1)) / TmpVal2;
If(FATType == FAT32) {
BPB_FATSz16 = 0;
BPB_FATSz32 = FATSz;
} else {
BPB_FATSz16 = LOWORD(FATSz);
/* there is no BPB_FATSz32 in a FAT16 BPB */
}
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. It will never compute a FATSz value that
is too
small, however. Because it is OK to have a FATSz that is too large, at
the expense
of wasting a few sectors, the fact that this computation is
surprisingly simple
more than makes up for it being off in a safe way in some cases.
"""
--------
"""
Name Offset(byte) Size(bytes) Description
BPB_RootClus 44 4
This field is only defined for FAT32 media and does not exist on
FAT12 and FAT16 media. This is set to the cluster number of the
first cluster of the root directory, usually 2 but not required to be
2.
NOTE: Disk utilities that change the location of the root directory
should make every effort to place the first cluster of the root
directory in the first non-bad cluster on the drive (i.e., in cluster
2,
unless it’s marked bad). This is specified so that disk repair
utilities
can easily find the root directory if this field accidentally gets
zeroed.
BPB_RsvdSecCnt 14 2
Number of reserved sectors in the Reserved region of the volume
starting at the first sector of the volume. This field must not be 0.
For FAT12 and FAT16 volumes, this value should never be
anything other than 1. For FAT32 volumes, this value is typically
32. There is a lot of FAT code in the world “hard wired” to 1
reserved sector for FAT12 and FAT16 volumes and that doesn’t
bother to check this field to make sure it is 1. Microsoft operating
systems will properly support any non-zero value in this field.
BPB_RootEntCnt 17 2
For FAT12 and FAT16 volumes, this field contains the count of 32-
byte directory entries in the root directory. For FAT32 volumes,
this field must be set to 0. For FAT12 and FAT16 volumes, this
value should always specify a count that when multiplied by 32
results in an even multiple of BPB_BytsPerSec. For maximum
compatibility, FAT16 volumes should use the value 512.
"""
--------
-my comments-
So, Fat32 has a BPB_RootEntCnt of 0 directory entries. This really
means
the directory is zero length, and what is called 'root' is not there.
Yet,
'root' is at CLU_2 as indicated by BPB_RootClus, and CLU_2 is the
starting
cluster of the volumes 'data area'. This differs from Fat12|16, where
root
is after Fat(s), and before CLU_2 -the first of the 'file data area'.
This
is alot like treating 'root' as an ordinary folder in Fat 12|16, ie.
as a
file.
..I'm scratching my head trying to figure if I have a Fat32 volume
around to check..
I'm not saying your algorithm is wrong at all, nor the one given in
fatgen103.
It's abit like being asked, 'How do I go north from here?' and given
the answer, "Follow the East Road.", where the answerer assumes you
know 'Legacy Lake' is just ahead and so the East Road is the best way
around it.
Steve