Discussion:
FAT type
(too old to reply)
muta...@gmail.com
2020-10-04 19:44:39 UTC
Permalink
What is the proper way to determine whether the
FAT boot sector is FAT 12/16 or FAT 32?

I could look at offset 0x36 for "FAT1" but that
offset is marked "reserved" in FAT32, so could
technically be anything.

Thanks. Paul.
wolfgang kern
2020-10-04 22:14:56 UTC
Permalink
Post by ***@gmail.com
What is the proper way to determine whether the
FAT boot sector is FAT 12/16 or FAT 32?
I could look at offset 0x36 for "FAT1" but that
offset is marked "reserved" in FAT32, so could
technically be anything.
according to M$'s white paper the FAT-type is only defined by count of
clusters, IIRC: smaller than 0xFFF5 is FAT16 and smaller than 0xff5 is
FAT 12. My memory may be wrong, so you better search this on the net.
__
wolfgang
JJ
2020-10-04 23:11:31 UTC
Permalink
Post by wolfgang kern
according to M$'s white paper the FAT-type is only defined by count of
clusters, IIRC: smaller than 0xFFF5 is FAT16 and smaller than 0xff5 is
FAT 12. My memory may be wrong, so you better search this on the net.
__
wolfgang
However, in practice, e.g. Windows 7 and MS-DOS 6 can still read a FAT16
custom formatted 1.4MB floppy disks - where it has total cluster number of
2^12 or less.

So, I could only conclude that the File System field is used as a hint to
support the FAT type resolved by the total number of cluster.

In above case, the total cluster number is 2^12 or less. That is by default,
suggest that the FAT type is FAT12. However, the total cluster number is
valid for both FAT12 and FAT16. So, if the File System field is either FAT12
or FAT16, then the FAT type is determined by the File System field.
Otherwise, the default suggested FAT type is used.
Bill Cunningham
2020-10-05 14:32:01 UTC
Permalink
Post by JJ
Post by wolfgang kern
according to M$'s white paper the FAT-type is only defined by count of
clusters, IIRC: smaller than 0xFFF5 is FAT16 and smaller than 0xff5 is
FAT 12. My memory may be wrong, so you better search this on the net.
__
wolfgang
However, in practice, e.g. Windows 7 and MS-DOS 6 can still read a FAT16
custom formatted 1.4MB floppy disks - where it has total cluster number of
2^12 or less.
So, I could only conclude that the File System field is used as a hint to
support the FAT type resolved by the total number of cluster.
In above case, the total cluster number is 2^12 or less. That is by default,
suggest that the FAT type is FAT12. However, the total cluster number is
valid for both FAT12 and FAT16. So, if the File System field is either FAT12
or FAT16, then the FAT type is determined by the File System field.
Otherwise, the default suggested FAT type is used.
Are you saying JJ that M$ OSes above Win 7 can't read FAT 16? The FATs are a very good family of FSes. I remember constantly having trouble with FAT 12. Whew! But since the kinks are worked out, they are really good FSes. I was waiting for a FAT64 and EXFat came out, just for USB sticks and such. It sucks some much. NTFS is ok, but the FATs are very fast now. I have a 30 Gb partition I have only FAT32 on. :) And I was thinking of going to Win 8.
JJ
2020-10-06 08:04:57 UTC
Permalink
Post by Bill Cunningham
Are you saying JJ that M$ OSes above Win 7 can't read FAT 16?
That's a complete misunderstanding.
muta...@gmail.com
2021-04-10 13:46:03 UTC
Permalink
Post by Bill Cunningham
Are you saying JJ that M$ OSes above Win 7 can't
read FAT 16? The FATs are a very good family of FSes.
I remember constantly having trouble with FAT 12.
Whew! But since the kinks are worked out, they are
really good FSes. I was waiting for a FAT64 and
EXFat came out, just for USB sticks and such. It
sucks some much. NTFS is ok, but the FATs are very
fast now. I have a 30 Gb partition I have only FAT32
on. :) And I was thinking of going to Win 8.
I am interested in supporting disks greater than
4 GiB, and up to 16 EiB, and files greater than
2 GiB and up to 8 EiB.

I have FAT-32 code already, which you can see here:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/src/fat.c

If FAT64 was never invented by Microsoft, then maybe
we can invent it ourselves. I'm hoping for minimal
changes to the fat32 code to implement 64-bit files.
I don't want any new features whatsoever.

I also don't want any C code exposed to disks greater
than an unsigned long (so that the OS reports free
space correctly), or files greater than a signed long
(so that fseek() is sensible).

So PDOS/386 is to be restricted to 4 GiB disks and
2 GiB files. Realistically I'll stick to FAT-16 and 2 GiB
disks.

But I'm getting close to making a move to PDOS/x64.

BFN. Paul.
muta...@gmail.com
2021-04-10 20:41:34 UTC
Permalink
Post by ***@gmail.com
I am interested in supporting disks greater than
4 GiB, and up to 16 EiB, and files greater than
2 GiB and up to 8 EiB.
I just realized that FAT-32 combined with 64-bit
longs will satisfy my needs for now. That gives
me 4 GiB files and I'm not sure what the disk
limit is, but it's at least 16 TiB.

I only have 2 files more than 4 GiB, both Debian ISOs,
and neither of any interest to me. Everything else
seems to be less than 2 GiB.

I'm planning on putting my life on a 16/32/whatever
GiB USB stick, ready to cross an international border.
A flat file on that disk, a hard disk image, to be read
by Bochs or whatever. Maybe even front-end it with
a legacy-boot PDOS/x64 designed to run PDOS-generic
from the flat file.

BFN. Paul.
Rod Pemberton
2021-04-11 08:21:42 UTC
Permalink
On Sat, 10 Apr 2021 06:46:03 -0700 (PDT)
Post by ***@gmail.com
I am interested in supporting disks greater than
4 GiB, and up to 16 EiB, and files greater than
2 GiB and up to 8 EiB.
...
Post by ***@gmail.com
If FAT64 was never invented by Microsoft, then maybe
we can invent it ourselves. I'm hoping for minimal
changes to the fat32 code to implement 64-bit files.
I don't want any new features whatsoever.
In general, I'm not sure that FAT is the correct platform to be used
for very large file systems.

E.g., M$ has concocted numerous FAT variations (FATX, exFAT, FAT+ etc)
but none of them is the default used by M$ nowadays, with M$ choosing
NTFS instead. Most of these FAT variations don't support very large
file systems. Although, it does seem that exFAT is capable of
supporting very large file systems. exFAT is used for storage such as
on USB sticks and SD cards, not for HDs or SDDs. However, exFAT is
patented and licensed.
--
Security breaches. Tax haven leaks. Someone is searching for a needle
in a haystack, but the needle isn't there.
wolfgang kern
2020-10-06 01:35:44 UTC
Permalink
Post by JJ
Post by wolfgang kern
according to M$'s white paper the FAT-type is only defined by count of
clusters, IIRC: smaller than 0xFFF5 is FAT16 and smaller than 0xff5 is
FAT 12. My memory may be wrong, so you better search this on the net.
__
wolfgang
However, in practice, e.g. Windows 7 and MS-DOS 6 can still read a FAT16
custom formatted 1.4MB floppy disks - where it has total cluster number of
2^12 or less.
So, I could only conclude that the File System field is used as a hint to
support the FAT type resolved by the total number of cluster.
In above case, the total cluster number is 2^12 or less. That is by default,
suggest that the FAT type is FAT12. However, the total cluster number is
valid for both FAT12 and FAT16. So, if the File System field is either FAT12
or FAT16, then the FAT type is determined by the File System field.
Otherwise, the default suggested FAT type is used.
quoted below to clear this up (from M$'s FAT specification)
__
wolfgang

3.5 Determination of FAT type when mounting the volume
The FAT type is determined solely by the count of clusters on the volume
(CountOfClusters).

The following steps describe the computation of the count of clusters:
1. First, determine the count of sectors occupied by the root directory:
RootDirSectors = ((BPB_RootEntCnt * 32) + (BPB_BytsPerSec – 1)) /
BPB_BytsPerSec
Note that on a FAT32 volume, the BPB_RootEntCnt value is always 0.
Therefore, on a
FAT32 volume, RootDirSectors is always 0.
2. Next, determine the count of sectors in the data region of the volume:
If(BPB_FATSz16 != 0)
FATSz = BPB_FATSz16;
Else
FATSz = BPB_FATSz32;
If(BPB_TotSec16 != 0)
TotSec = BPB_TotSec16;
Else
TotSec = BPB_TotSec32;
DataSec = TotSec – (BPB_ResvdSecCnt + (BPB_NumFATs * FATSz) +
RootDirSectors);
3. Lastly, determine the count of clusters as:
CountofClusters = DataSec / BPB_SecPerClus;

Microsoft FAT Specification
Microsoft Confidential. © 2004 Microsoft Corporation. All rights
reserved Page 15

The computation rounds down.
To determine the FAT type, the following algorithm is used:
If(CountofClusters < 4085) {
/* Volume is FAT12 */
} else if(CountofClusters < 65525) {
/* Volume is FAT16 */
} else {
/* Volume is FAT32 */
}
The above algorithm determines the FAT type. Note the following:
• A FAT12 volume cannot contain more than 4084 clusters.
• A FAT16 volume cannot contain less than 4085 clusters or more than
65,524 clusters.
It is recommended that volumes not be created with a count of clusters
that is exactly equal to the
boundary values listed above (i.e. 4085 clusters or 65525 clusters).1
The Maximum Valid Cluster Number (MAX) for the volume is
(CountofClusters + 1).
The “count of clusters including the two reserved clusters” is
(CountofClusters + 2).
JJ
2020-10-06 08:27:37 UTC
Permalink
Post by wolfgang kern
quoted below to clear this up (from M$'s FAT specification)
__
wolfgang
3.5 Determination of FAT type when mounting the volume
The FAT type is determined solely by the count of clusters on the volume
(CountOfClusters).
RootDirSectors = ((BPB_RootEntCnt * 32) + (BPB_BytsPerSec – 1)) /
BPB_BytsPerSec
Note that on a FAT32 volume, the BPB_RootEntCnt value is always 0.
Therefore, on a
FAT32 volume, RootDirSectors is always 0.
If(BPB_FATSz16 != 0)
FATSz = BPB_FATSz16;
Else
FATSz = BPB_FATSz32;
If(BPB_TotSec16 != 0)
TotSec = BPB_TotSec16;
Else
TotSec = BPB_TotSec32;
DataSec = TotSec – (BPB_ResvdSecCnt + (BPB_NumFATs * FATSz) +
RootDirSectors);
CountofClusters = DataSec / BPB_SecPerClus;
Microsoft FAT Specification
Microsoft Confidential. © 2004 Microsoft Corporation. All rights
reserved Page 15
The computation rounds down.
If(CountofClusters < 4085) {
/* Volume is FAT12 */
} else if(CountofClusters < 65525) {
/* Volume is FAT16 */
} else {
/* Volume is FAT32 */
}
• A FAT12 volume cannot contain more than 4084 clusters.
• A FAT16 volume cannot contain less than 4085 clusters or more than
65,524 clusters.
It is recommended that volumes not be created with a count of clusters
that is exactly equal to the
boundary values listed above (i.e. 4085 clusters or 65525 clusters).1
The Maximum Valid Cluster Number (MAX) for the volume is
(CountofClusters + 1).
The “count of clusters including the two reserved clusters” is
(CountofClusters + 2).
OK, so it states that:

"The FAT type is determined solely by the count of clusters on the volume
(CountOfClusters)."

But the fact is, a 1.44MB floppy disk formatted as FAT16, is still
recognized as having FAT16, instead of FAT12. Despite it has less than 4085
clusters.

IOTW, Windows and MS-DOS (at least Windows 7 and MS-DOS 6) don't conform to
its own FAT specification.

Here's the FAT16 floppy disk image. It already contains two text files and a
subdirectory. It's fully usable for reading and writing.

https://drive.google.com/file/d/151-uuk_KqXbnug9Ixrgj-_gi_cG0jMzv/view
wolfgang kern
2020-10-07 12:37:45 UTC
Permalink
On 06.10.2020 10:27, JJ wrote:
...
Post by JJ
"The FAT type is determined solely by the count of clusters on the volume
(CountOfClusters)."
But the fact is, a 1.44MB floppy disk formatted as FAT16, is still
recognized as having FAT16, instead of FAT12. Despite it has less than 4085
clusters.
IOTW, Windows and MS-DOS (at least Windows 7 and MS-DOS 6) don't conform to
its own FAT specification.
You mean the M$-format tools aren't/weren't conform ?
I can't check FDs because there are no drives in my machines anymore.
Post by JJ
Here's the FAT16 floppy disk image. It already contains two text files and a
subdirectory. It's fully usable for reading and writing.
https://drive.google.com/file/d/151-uuk_KqXbnug9Ixrgj-_gi_cG0jMzv/view
Yes, DOS600 and win7 and perhaps also some newer accept non-conform FAT.

My OS can read any FAT_n (n as a multiple of four) by coincidence
because long ago I made one single routine for FAT 12, 16, 32(28) and a
non-M$ FAT32(true 32 bit). It is short so I kept it, the indicators
became 3,4,7,8 which work on 4-bit nibbles just fine. But my own
filesystem isn't FAT anyway, this routine was used for data import only.
__
wolfgang
JJ
2020-10-08 05:29:50 UTC
Permalink
Post by wolfgang kern
You mean the M$-format tools aren't/weren't conform ?
The OSes.

FORMAT tool doesn't use the OS' file system drivers, and it does conform to
the FAT specification. e.g. it refuses to format 1.44MB floppy as FAT16.
Post by wolfgang kern
I can't check FDs because there are no drives in my machines anymore.
For Windows, use ImDisk for virtual floppy drive.
wolfgang kern
2020-10-08 06:56:07 UTC
Permalink
Post by JJ
Post by wolfgang kern
You mean the M$-format tools aren't/weren't conform ?
The OSes.
FORMAT tool doesn't use the OS' file system drivers, and it does conform to
the FAT specification. e.g. it refuses to format 1.44MB floppy as FAT16.
Post by wolfgang kern
I can't check FDs because there are no drives in my machines anymore.
For Windows, use ImDisk for virtual floppy drive.
Thanks a lot, but how to insert a disk into ? :)
__
wolfgang
Kerr-Mudd,John
2020-10-08 16:39:23 UTC
Permalink
Post by wolfgang kern
Post by JJ
Post by wolfgang kern
You mean the M$-format tools aren't/weren't conform ?
The OSes.
FORMAT tool doesn't use the OS' file system drivers, and it does
conform to the FAT specification. e.g. it refuses to format 1.44MB
floppy as FAT16.
Post by wolfgang kern
I can't check FDs because there are no drives in my machines
anymore.
For Windows, use ImDisk for virtual floppy drive.
Thanks a lot, but how to insert a disk into ? :)
I've imaged the disk, now where do I post the photo?
:-)
--
Bah, and indeed, Humbug.
JJ
2020-10-09 04:12:09 UTC
Permalink
Post by wolfgang kern
Thanks a lot, but how to insert a disk into ? :)
Right click on the floppy image. Choose "Mount as ImDisk Virtual Floppy". Or
manually mount it from the ImDisk application.

Removing the floppy disk from the drive can be done by using the "Eject"
menu from its drive's right-click popup menu. Like ejecting CD-ROM.
James Harris
2021-04-05 23:46:46 UTC
Permalink
Post by JJ
Post by wolfgang kern
quoted below to clear this up (from M$'s FAT specification)
...
Post by JJ
Post by wolfgang kern
3.5 Determination of FAT type when mounting the volume
The FAT type is determined solely by the count of clusters on the volume
(CountOfClusters).
...
Post by JJ
"The FAT type is determined solely by the count of clusters on the volume
(CountOfClusters)."
But the fact is, a 1.44MB floppy disk formatted as FAT16, is still
recognized as having FAT16, instead of FAT12. Despite it has less than 4085
clusters.
IOTW, Windows and MS-DOS (at least Windows 7 and MS-DOS 6) don't conform to
its own FAT specification.
Here's the FAT16 floppy disk image. It already contains two text files and a
subdirectory. It's fully usable for reading and writing.
https://drive.google.com/file/d/151-uuk_KqXbnug9Ixrgj-_gi_cG0jMzv/view
That sounds interesting but how do you know it's really FAT16?

I notice that the files are less than a sector in size so accessing them
won't test that their FAT chains will genuinely operate as either FAT12
or FAT16.

Windows XP just reports the filesystem as of type FAT. Where in Windows
7 and MS-DOS 6 did you see the filesystem shown as of type FAT16?
--
James Harris
JJ
2021-04-06 06:55:52 UTC
Permalink
Post by James Harris
That sounds interesting but how do you know it's really FAT16?
I notice that the files are less than a sector in size so accessing them
won't test that their FAT chains will genuinely operate as either FAT12
or FAT16.
Windows XP just reports the filesystem as of type FAT. Where in Windows
7 and MS-DOS 6 did you see the filesystem shown as of type FAT16?
By checking the boot record and the FAT. In Windows XP (32-bit), it can be
done using DEBUG. Otherwise, use a disk editor application.
James Harris
2021-04-06 09:10:04 UTC
Permalink
Post by JJ
Post by James Harris
That sounds interesting but how do you know it's really FAT16?
I notice that the files are less than a sector in size so accessing them
won't test that their FAT chains will genuinely operate as either FAT12
or FAT16.
Windows XP just reports the filesystem as of type FAT. Where in Windows
7 and MS-DOS 6 did you see the filesystem shown as of type FAT16?
By checking the boot record and the FAT. In Windows XP (32-bit), it can be
done using DEBUG. Otherwise, use a disk editor application.
What specifically did you check for in the boot record and the FATs?

And won't they have in them whatever was put there when the image was
created?

I see that you have BS_FilSysType as "FAT16 " but there's no point
using that as an indicator of how MS operating systems interpret the
contents as they are supposed to ignore that field (at least according
to the fatgen103 document).

Similarly, your FATs having

f0 ff ff ff ff ff ff 0f

may or may not look like FAT16 but, either way, that doesn't indicate
how MS operating systems would interpret the contents.

I started looking at this as I was intrigued by your comment and if you
are right I wondered what criteria MS actually used.
--
James Harris
Rod Pemberton
2021-04-06 11:29:07 UTC
Permalink
On Tue, 6 Apr 2021 10:10:04 +0100
Post by James Harris
Post by JJ
Post by James Harris
That sounds interesting but how do you know it's really FAT16?
By checking the boot record and the FAT. In Windows XP (32-bit), it
can be done using DEBUG. Otherwise, use a disk editor application.
What specifically did you check for in the boot record and the FATs?
I started looking at this as I was intrigued by your comment and if
you are right I wondered what criteria MS actually used.
Are you thinking that M$ used a different mechanism(s) prior to the
FAT32 specification (2000)? FAT did exist for two decades prior to
that document. Perhaps, they used a method that was more robust and/or
also calculated the FAT type from methods other than the cluster count?

Another question could be, does a floppy recognized as FAT16 on an
earlier version of Windows (3.1, 98/SE/ME, NT) still recognize as FAT16
on a later version of Windows (XP, Vista, 7, 8, 10)? In other words,
do later versions of Windows comply with the FAT32 specification for
detecting FAT type by cluster count, but earlier versions don't?
--
Facebook's security is like a water bucket that's full of bullet holes.
James Harris
2021-04-06 11:15:56 UTC
Permalink
Post by Rod Pemberton
On Tue, 6 Apr 2021 10:10:04 +0100
Post by James Harris
Post by JJ
Post by James Harris
That sounds interesting but how do you know it's really FAT16?
By checking the boot record and the FAT. In Windows XP (32-bit), it
can be done using DEBUG. Otherwise, use a disk editor application.
What specifically did you check for in the boot record and the FATs?
I started looking at this as I was intrigued by your comment and if
you are right I wondered what criteria MS actually used.
Are you thinking that M$ used a different mechanism(s) prior to the
FAT32 specification (2000)? FAT did exist for two decades prior to
that document. Perhaps, they used a method that was more robust and/or
also calculated the FAT type from methods other than the cluster count?
Another question could be, does a floppy recognized as FAT16 on an
earlier version of Windows (3.1, 98/SE/ME, NT) still recognize as FAT16
on a later version of Windows (XP, Vista, 7, 8, 10)? In other words,
do later versions of Windows comply with the FAT32 specification for
detecting FAT type by cluster count, but earlier versions don't?
According to fatgen103:

"In MS-DOS version 1.x, ... The determination of which type was on
the disk was done by looking at the first byte of the FAT (the low 8
bits of FAT[0]).

"This type of media determination was superseded in MS-DOS version
2.x by putting a BPB in the boot sector, and the old style of media
determination (done by looking at the first byte of the FAT)
was no longer supported."

I mention that as it shows that Microsoft say their 'one true way' of
determining the FAT type goes as far back as MS-DOS 2.x. That's why JJ's
claim that MS operating systems can treat a floppy as of FAT16 is so
surprising and IMO worth checking out.

FWIW I make JJ's floppy image's 'count of clusters' 2847 which is well
below the 4084 that fatgen103 indicates to be the upper limit of FAT12.
The document states explicitly:

"There is no such thing as a FAT16 volume that has less than 4085
clusters"

The thing is how best to determine what any particular MS OS thinks an
image has as its FAT filesystem. I guess one way would be to write a
lengthy file to it and see whether the FAT tables are filled with 12-bit
or 16-bit entries, but maybe there's a better way.

And if JJ is right and fatgen103 is wrong then the mystery is as to how
MS OSes really do make the determination.
--
James Harris
wolfgang kern
2021-04-06 13:35:51 UTC
Permalink
On 06.04.2021 13:15, James Harris wrote:
...
Post by James Harris
That sounds interesting but how do you know it's really FAT16?
...
 "In MS-DOS version 1.x, ... The determination of which type was on the
disk was done by looking at the first byte of the FAT (the low 8 bits of
FAT[0]).
 "This type of media determination was superseded in MS-DOS version 2.x
by putting a BPB in the boot sector, and the old style of media
determination (done by looking at the first byte of the FAT)
was no longer supported."
I mention that as it shows that Microsoft say their 'one true way' of
determining the FAT type goes as far back as MS-DOS 2.x. That's why JJ's
claim that MS operating systems can treat a floppy as of FAT16 is so
surprising and IMO worth checking out.
FWIW I make JJ's floppy image's 'count of clusters' 2847 which is well
below the 4084 that fatgen103 indicates to be the upper limit of FAT12.
 "There is no such thing as a FAT16 volume that has less than 4085
clusters"
:) you never read a hex dump of an MBR ?

you'll see a string: either "FAT12" or "FAT16" or "FAT32"

even M$-white papers declare this strings aren't valid anymore.
The thing is how best to determine what any particular MS OS thinks an
image has as its FAT filesystem. I guess one way would be to write a
lengthy file to it and see whether the FAT tables are filled with 12-bit
or 16-bit entries, but maybe there's a better way.
And if JJ is right and fatgen103 is wrong then the mystery is as to how
MS OSes really do make the determination.
I actually used (several decades ago) these string info in FD-MBR.
__
wolfgang
James Harris
2021-04-06 15:32:11 UTC
Permalink
Post by wolfgang kern
...
Post by James Harris
That sounds interesting but how do you know it's really FAT16?
...
  "In MS-DOS version 1.x, ... The determination of which type was on
the disk was done by looking at the first byte of the FAT (the low 8
bits of FAT[0]).
  "This type of media determination was superseded in MS-DOS version
2.x by putting a BPB in the boot sector, and the old style of media
determination (done by looking at the first byte of the FAT)
was no longer supported."
I mention that as it shows that Microsoft say their 'one true way' of
determining the FAT type goes as far back as MS-DOS 2.x. That's why
JJ's claim that MS operating systems can treat a floppy as of FAT16 is
so surprising and IMO worth checking out.
FWIW I make JJ's floppy image's 'count of clusters' 2847 which is well
below the 4084 that fatgen103 indicates to be the upper limit of
  "There is no such thing as a FAT16 volume that has less than 4085
clusters"
:) you never read a hex dump of an MBR ?
Do you mean a VBR?

https://www.techopedia.com/definition/25922/volume-boot-record-vbr
https://en.wikipedia.org/wiki/Volume_boot_record
https://en.wikipedia.org/wiki/Master_boot_record
Post by wolfgang kern
you'll see a string: either "FAT12" or "FAT16" or "FAT32"
even M$-white papers declare this strings aren't valid anymore.
AFAIK they never were!
--
James Harris
wolfgang kern
2021-04-07 08:18:20 UTC
Permalink
On 06.04.2021 17:32, James Harris wrote:
...
Post by James Harris
Post by wolfgang kern
 "There is no such thing as a FAT16 volume that has less than 4085
clusters"
:) you never read a hex dump of an MBR ?
Do you mean a VBR?
Yeah, for me both are equal because my OS have them combined.
Post by James Harris
Post by wolfgang kern
you'll see a string: either "FAT12" or "FAT16" or "FAT32"
even M$-white papers declare this strings aren't valid anymore.
AFAIK they never were!
until 2000 they were really widely used and they may be still found on
new formatted volumes.
Even all BIOS looked at this, I haven't checked on new stuff yet.

FAT12/16 FAT32
_____________________|_____________________|
000 c EB xx 90 = equal but xx>3C
003 s8 OEM-name =
00b w BytesPerSector =
00d b SectorsPerCluster =
00e w ReservedSectors =
010 b FATcopies (2) 0
011 w RootEntriesLimit* 0
013 w SectorsInVolume* 0
015 b MediaDescriptor =
016 w SectorsPerFAT* 0
018 w SectorsPerTrack =
01a w Heads =
01c q HiddenSectors =
020 q TotalSectors 0
--------FAT12/16 |FAT32
024 b DriveNumber |at 040
025 b 0 |at 041
026 b ExtSignature 29 |at 042
027 q SerialNumber |at 043
02b s11 VolumeName |at 047
036 s8 "FATxx " |at 052 s8 "FAT32 "
03E ...
--------FAT32 only |NTFS
024 q SectorsPerFAT x80008000
028 q flags + FS-Version TotalSectorsLow
02c q RootCluster TotalSectorsHigh
030 q Info+BackupSector $MFTClusterLow
034 q 0 $MFTClusterHigh
038 dq 0 $MFTMirrCluster
040 q (40..59 as 24..3d) ClustersPerFRS
05A ...
-------NTFS only
044 q ClustersPerIndexBlock
048 dq VolumeSerialNumber
050 w 0 (Checksum)
052...
__
wolfgang
Rod Pemberton
2021-04-07 09:33:51 UTC
Permalink
On Tue, 6 Apr 2021 12:15:56 +0100
Post by James Harris
The thing is how best to determine what any particular MS OS thinks
an image has as its FAT filesystem. I guess one way would be to write
a lengthy file to it and see whether the FAT tables are filled with
12-bit or 16-bit entries, but maybe there's a better way.
What were you thinking here? A dual-mode FAT12/FAT16 image?

E.g., FAT table which could be interpreted as either FAT12 or FAT16 by
the OS? Are the directories for FAT12 and FAT16 in different locations
on the disk? I.e., if so, if FAT12 directory is in one area and FAT16
directory is in another, then a DIR command would pull up different
directories, depending upon whether the disk image is treated as FAT12
or FAT16.
--
Facebook's security is like a water bucket that's full of bullet holes.
Facebook fact checked a person who died from from the COVID vaccine.
James Harris
2021-04-07 10:11:14 UTC
Permalink
Post by Rod Pemberton
On Tue, 6 Apr 2021 12:15:56 +0100
Post by James Harris
The thing is how best to determine what any particular MS OS thinks
an image has as its FAT filesystem. I guess one way would be to write
a lengthy file to it and see whether the FAT tables are filled with
12-bit or 16-bit entries, but maybe there's a better way.
What were you thinking here? A dual-mode FAT12/FAT16 image?
No, it wasn't my suggestion. JJ said back in October that he was posting
a link to the image of a FAT16 floppy and that intrigued me but I didn't
have time to look into it.

In the event it turned out that the image was still FAT12 according to
fatgen103 and to a Microsoft OS that I just tested it on (XP). Putting
"FAT16 " in the record is just a potential cause of confusion.
--
James Harris
JJ
2021-04-07 01:23:50 UTC
Permalink
Post by James Harris
What specifically did you check for in the boot record and the FATs?
And won't they have in them whatever was put there when the image was
created?
The boot record's files system field. And checking the enries of the FAT
will make sure of which type of FAT is actually used.
Post by James Harris
I see that you have BS_FilSysType as "FAT16 " but there's no point
using that as an indicator of how MS operating systems interpret the
contents as they are supposed to ignore that field (at least according
to the fatgen103 document).
True.
Post by James Harris
Similarly, your FATs having
f0 ff ff ff ff ff ff 0f
may or may not look like FAT16 but, either way, that doesn't indicate
how MS operating systems would interpret the contents.
The data has to be validated. Based on the file system type suggested by
boot record.
James Harris
2021-04-07 10:04:51 UTC
Permalink
Post by JJ
Post by James Harris
What specifically did you check for in the boot record and the FATs?
And won't they have in them whatever was put there when the image was
created?
The boot record's files system field. And checking the enries of the FAT
will make sure of which type of FAT is actually used.
Post by James Harris
I see that you have BS_FilSysType as "FAT16 " but there's no point
using that as an indicator of how MS operating systems interpret the
contents as they are supposed to ignore that field (at least according
to the fatgen103 document).
True.
Post by James Harris
Similarly, your FATs having
f0 ff ff ff ff ff ff 0f
may or may not look like FAT16 but, either way, that doesn't indicate
how MS operating systems would interpret the contents.
The data has to be validated. Based on the file system type suggested by
boot record.
On the contrary, I've just mounted your image as A: and written a
multi-cluster file to it. The resulting FAT shows

f0 ff ff ff ff ff ff 6f 00 07 80 00 09 a0 00 0b
c0 00 0d f0 ff 00 00 00 00 00 00 00 00 00 00 00

The first 8 bytes are what were there before but note what follows. In

00 07 80 00 09 a0 00 0b

those FAT entries are clearly 12-bit, not 16-bit.

IOW the "FAT16 " text at 0x36 is irrelevant to Microsoft. They still
treat the file as a FAT12 floppy image, not a FAT16 one.
--
James Harris
wolfgang kern
2021-04-07 15:09:52 UTC
Permalink
Post by James Harris
Post by JJ
Post by James Harris
What specifically did you check for in the boot record and the FATs?
And won't they have in them whatever was put there when the image was
created?
The boot record's files system field. And checking the enries of the FAT
will make sure of which type of FAT is actually used.
Post by James Harris
I see that you have BS_FilSysType as "FAT16   " but there's no point
using that as an indicator of how MS operating systems interpret the
contents as they are supposed to ignore that field (at least according
to the fatgen103 document).
True.
Post by James Harris
Similarly, your FATs having
    f0 ff ff ff ff ff ff 0f
may or may not look like FAT16 but, either way, that doesn't indicate
how MS operating systems would interpret the contents.
The data has to be validated. Based on the file system type suggested by
boot record.
On the contrary, I've just mounted your image as A: and written a
multi-cluster file to it. The resulting FAT shows
f0 ff ff ff ff ff ff 6f  00 07 80 00 09 a0 00 0b
c0 00 0d f0 ff 00 00 00  00 00 00 00 00 00 00 00
The first 8 bytes are what were there before but note what follows. In
 00 07 80 00 09 a0 00 0b
those FAT entries are clearly 12-bit, not 16-bit.
IOW the "FAT16   " text at 0x36 is irrelevant to Microsoft. They still
treat the file as a FAT12 floppy image, not a FAT16 one.
M$ may really use what it tells in the white papers ...
what were count of clusters there ?

looks like JJ posted a format which were modified by wrong DOS-sys vsn.

here is a short copy from my (confidential) M$ pages:
------
4.2 Reserved FAT entries
The first two entries in the FAT are reserved.
The first reserved entry (FAT[0]), contains the BPB_Media byte value in
its low 8 bits, and all other bits are set to 1. For example, if the
BPB_Media value is 0xF8, then:

 for FAT12, FAT[0] = 0x0FF8
 for FAT16, FAT[0] = 0xFFF8
 for FAT32 FAT[0] = 0x0FFFFFF8

The second reserved entry (FAT[1]), is set by the format utility to the
EOC value.
 On FAT12 volumes, this entry is not modified subsequent to the format
and, therefore, always contains an EOC mark.
---------
BUT it doesn't make much sense because ff0 followed by fff just looks
equal to fff0
__
wolfgang
James Harris
2021-04-08 12:58:35 UTC
Permalink
Post by wolfgang kern
Post by James Harris
Post by JJ
Post by James Harris
What specifically did you check for in the boot record and the FATs?
And won't they have in them whatever was put there when the image was
created?
The boot record's files system field. And checking the enries of the FAT
will make sure of which type of FAT is actually used.
Post by James Harris
I see that you have BS_FilSysType as "FAT16   " but there's no point
using that as an indicator of how MS operating systems interpret the
contents as they are supposed to ignore that field (at least according
to the fatgen103 document).
True.
Post by James Harris
Similarly, your FATs having
    f0 ff ff ff ff ff ff 0f
may or may not look like FAT16 but, either way, that doesn't indicate
how MS operating systems would interpret the contents.
The data has to be validated. Based on the file system type suggested by
boot record.
On the contrary, I've just mounted your image as A: and written a
multi-cluster file to it. The resulting FAT shows
f0 ff ff ff ff ff ff 6f  00 07 80 00 09 a0 00 0b
c0 00 0d f0 ff 00 00 00  00 00 00 00 00 00 00 00
The first 8 bytes are what were there before but note what follows. In
  00 07 80 00 09 a0 00 0b
those FAT entries are clearly 12-bit, not 16-bit.
IOW the "FAT16   " text at 0x36 is irrelevant to Microsoft. They still
treat the file as a FAT12 floppy image, not a FAT16 one.
M$ may really use what it tells in the white papers ...
what were count of clusters there ?
looks like JJ posted a format which were modified by wrong DOS-sys vsn.
------
4.2 Reserved FAT entries
The first two entries in the FAT are reserved.
The first reserved entry (FAT[0]), contains the BPB_Media byte value in
its low 8 bits, and all other bits are set to 1. For example, if the
 for FAT12, FAT[0] = 0x0FF8
 for FAT16, FAT[0] = 0xFFF8
 for FAT32 FAT[0] = 0x0FFFFFF8
The second reserved entry (FAT[1]), is set by the format utility to the
EOC value.
 On FAT12 volumes, this entry is not modified subsequent to the format
and, therefore, always contains an EOC mark.
---------
BUT it doesn't make much sense because ff0 followed by fff just looks
equal to fff0
If FAT[0] is the first FAT and FAT[0][0] is the first 12-bit, 16-bit or
32-bit entry in that FAT then all three, above, represent the same 2's
complement value so is there a problem?

FWIW there's a very clear, colour coded, set of examples of 12-bit,
16-bit and 32-bit FAT entries at
https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#Cluster_map
--
James Harris
wolfgang kern
2021-04-10 06:27:28 UTC
Permalink
On 08.04.2021 14:58, James Harris wrote:
...
Post by James Harris
Post by wolfgang kern
The second reserved entry (FAT[1]), is set by the format utility to
the EOC value.
 On FAT12 volumes, this entry is not modified subsequent to the
format and, therefore, always contains an EOC mark.
---------
BUT it doesn't make much sense because ff0 followed by fff just looks
equal to fff0
If FAT[0] is the first FAT and FAT[0][0] is the first 12-bit, 16-bit or
32-bit entry in that FAT then all three, above, represent the same 2's
complement value so is there a problem?
FWIW there's a very clear, colour coded, set of examples of 12-bit,
16-bit and 32-bit FAT entries at
https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#Cluster_map
yes, we better stick to "count of clusters" for determination even some
handmade formatting variants may fail on this.

So your "always be sure demand" would need additional checks:
* 2nd byte of the VBR is 3A,3C,3E or >=5c. it may give a hint to format
* consecutive FAT-entry checks (like you did manually)
* root size limit could be an indication too.
__
wolfgang
JJ
2021-04-10 09:22:05 UTC
Permalink
Post by wolfgang kern
yes, we better stick to "count of clusters" for determination even some
handmade formatting variants may fail on this.
* 2nd byte of the VBR is 3A,3C,3E or >=5c. it may give a hint to format
* consecutive FAT-entry checks (like you did manually)
* root size limit could be an indication too.
The maximum cluster size for FAT16 is still confusing, though. At least for
me.

In below Wikipedia article:

https://en.wikipedia.org/wiki/File_Allocation_Table#Initial_FAT16

In "Initial FAT16" section, it states that the maximum clusters is 65524.
However, in the "FAT16" right side floating section, it says 65536 which is
incorrect because cluster number 0x0000, 0x0001, and 0xFFF0-0xFFFF, are not
for data cluster numbers. Theorically, the maximum is 65536 minus 18, or
65518.

In below archived Windows XP Resource Kit article: (long URL warning)

<https://web.archive.org/web/20060307082555/http://www.microsoft.com/technet/prodtechnol/winxppro/reskit/c13621675.mspx#EACBIAA>

In "Maximum Sizes on FAT16 Volumes" section, it also states that the maximum
is 65524. But this value is also beyond the theorical limit above.

Adding to the confusion, in "Maximum Sizes on FAT32 Volumes" section, it
states that the minimum cluster number is 65527. So if that's the case, what
happen to FAT file systems if they end up having 65525 to 65526? Should it
be FAT16, FAT32, or shouldn't exist at all?
wolfgang kern
2021-04-10 19:07:36 UTC
Permalink
Post by JJ
Post by wolfgang kern
yes, we better stick to "count of clusters" for determination even some
handmade formatting variants may fail on this.
* 2nd byte of the VBR is 3A,3C,3E or >=5c. it may give a hint to format
* consecutive FAT-entry checks (like you did manually)
* root size limit could be an indication too.
The maximum cluster size for FAT16 is still confusing, though. At least for
me.
https://en.wikipedia.org/wiki/File_Allocation_Table#Initial_FAT16
In "Initial FAT16" section, it states that the maximum clusters is 65524.
However, in the "FAT16" right side floating section, it says 65536 which is
incorrect because cluster number 0x0000, 0x0001, and 0xFFF0-0xFFFF, are not
for data cluster numbers. Theorically, the maximum is 65536 minus 18, or
65518.
In below archived Windows XP Resource Kit article: (long URL warning)
<https://web.archive.org/web/20060307082555/http://www.microsoft.com/technet/prodtechnol/winxppro/reskit/c13621675.mspx#EACBIAA>
In "Maximum Sizes on FAT16 Volumes" section, it also states that the maximum
is 65524. But this value is also beyond the theorical limit above.
Adding to the confusion, in "Maximum Sizes on FAT32 Volumes" section, it
states that the minimum cluster number is 65527. So if that's the case, what
happen to FAT file systems if they end up having 65525 to 65526? Should it
be FAT16, FAT32, or shouldn't exist at all?
there are exact limits defined, but not every formatting tool knows it.

M$ FAT specs say:

• For 512 byte sector sized media: if volume size is < 512 MB, the
volume is formatted
FAT16 else it is formatted FAT32. It is possible to override the default
FAT type selection.
The below tables are used by the Microsoft Corporation FAT format
utility - an entry in these
tables is selected based on the size of the volume in 512 byte sectors
(the value that will go
in BPB_TotSec16 or BPB_TotSec32), and the value that this table sets is the
BPB_SecPerClus value:
struct DSKSZTOSECPERCLUS {
DWORD DiskSize;
BYTE SecPerClusVal;
};
/*
*This is the table for FAT16 drives. NOTE that this table includes
* entries for disk sizes larger than 512 MB even though typically
* only the entries for disks < 512 MB in size are used.
* The way this table is accessed is to look for the first entry
* in the table for which the disk size is less than or equal
* to the DiskSize field in that table entry. For this table to
* work properly BPB_RsvdSecCnt must be 1, BPB_NumFATs
* must be 2, and BPB_RootEntCnt must be 512. Any of these values
* being different may require the first table entries DiskSize value
* to be changed otherwise the cluster count may be to low for FAT16.
*/
DSKSZTOSECPERCLUS DskTableFAT16 [] = {
{8400, 0}, /* disks up to 4.1 MB, the 0 value for SecPerClusVal trips an
error */
{32680, 2}, /* disks up to 16 MB, 1k cluster */
{262144, 4}, /* disks up to 128 MB, 2k cluster */
{524288, 8}, /* disks up to 256 MB, 4k cluster */
{1048576, 16}, /* disks up to 512 MB, 8k cluster */
/* The entries after this point are not used unless FAT16 is forced */
{2097152, 32}, /* disks up to 1 GB, 16k cluster */
{4194304, 64}, /* disks up to 2 GB, 32k cluster */
{0xFFFFFFFF, 0} /*any disk greater than 2GB, 0 value for SecPerClusVal
trips an error */
};
/*
* This is the table for FAT32 drives. NOTE that this table includes
* entries for disk sizes smaller than 512 MB even though typically
* only the entries for disks >= 512 MB in size are used.
* The way this table is accessed is to look for the first entry
* in the table for which the disk size is less than or equal
* to the DiskSize field in that table entry. For this table to
* work properly BPB_RsvdSecCnt must be 32, and BPB_NumFATs
* must be 2. Any of these values being different may require the first
* table entries DiskSize value to be changed otherwise the cluster count
* may be to low for FAT32.
*/
DSKSZTOSECPERCLUS DskTableFAT32 [] = {
{66600, 0}, /* disks up to 32.5 MB, the 0 value for SecPerClusVal trips
an error */
{532480, 1}, /* disks up to 260 MB, .5k cluster */
{16777216, 8}, /* disks up to 8 GB, 4k cluster */
{33554432, 16}, /* disks up to 16 GB, 8k cluster */
{67108864, 32}, /* disks up to 32 GB, 16k cluster */
{0xFFFFFFFF, 64}/* disks greater than 32GB, 32k cluster */
};
Given a disk size and a FAT type of FAT16 or FAT32, the above determines the
BPB_SecPerClus value.
...
The FAT type is determined solely by the count of clusters on the volume
(CountOfClusters).
The following steps describe the computation of the count of clusters:
1. First, determine the count of sectors occupied by the root directory:
RootDirSectors = ((BPB_RootEntCnt * 32) + (BPB_BytsPerSec – 1)) /
BPB_BytsPerSec
Note that on a FAT32 volume, the BPB_RootEntCnt value is always 0.
Therefore, on a
FAT32 volume, RootDirSectors is always 0.
2. Next, determine the count of sectors in the data region of the volume:
If(BPB_FATSz16 != 0)
FATSz = BPB_FATSz16;
Else
FATSz = BPB_FATSz32;
If(BPB_TotSec16 != 0)
TotSec = BPB_TotSec16;
Else
TotSec = BPB_TotSec32;
DataSec = TotSec – (BPB_ResvdSecCnt + (BPB_NumFATs * FATSz) +
RootDirSectors);
3. Lastly, determine the count of clusters as:
CountofClusters = DataSec / BPB_SecPerClus;
</>

confusing ? :) another M$ white paper tells cluster count limits to
be <= f4 0ff4 fff4 (total, including first two)
__
wolfgang
JJ
2021-04-11 09:20:37 UTC
Permalink
Post by wolfgang kern
confusing ? :)
Not for me. It's a good info.
Post by wolfgang kern
another M$ white paper tells cluster count limits to
be <= f4 0ff4 fff4 (total, including first two)
My question was for FAT16 max cluster count. In the last paragraph of my
previous post, I stated the _minimum_(not the maximum) cluster number for
FAT32. i.e. the boundary between FAT16 and FAT32. Because that info cam be
used as a hint for the maximum cluster number for FAT16.
wolfgang kern
2021-04-12 10:10:28 UTC
Permalink
Post by JJ
Post by wolfgang kern
confusing ? :)
Not for me. It's a good info.
Post by wolfgang kern
another M$ white paper tells cluster count limits to
be <= f4 0ff4 fff4 (total, including first two)
My question was for FAT16 max cluster count. In the last paragraph of my
previous post, I stated the _minimum_(not the maximum) cluster number for
FAT32. i.e. the boundary between FAT16 and FAT32. Because that info cam be
used as a hint for the maximum cluster number for FAT16.
I (my OS does) calculate max cluster-## (needed for access-checks)

512*[sectors per FAT]/[nibbles per entry] rounded down by AND FFFFFFF4

it seem there is a gap between max FAT12 and min FAT16 because of
geometry vs. xxx4 limit issues. same for max FAT16 and min FAT32
cluster-size.
__
wolfgang
JJ
2021-04-12 16:14:20 UTC
Permalink
Post by wolfgang kern
I (my OS does) calculate max cluster-## (needed for access-checks)
512*[sectors per FAT]/[nibbles per entry] rounded down by AND FFFFFFF4
it seem there is a gap between max FAT12 and min FAT16 because of
geometry vs. xxx4 limit issues. same for max FAT16 and min FAT32
cluster-size.
If I use that calculation, the standard 3.5" 1.4MB floppy format would be
seen as incorrect because it has a total clusters of 2847. It's not evenly
divisible by 4.
Bernhard Schornak
2021-04-12 20:04:56 UTC
Permalink
Post by JJ
Post by wolfgang kern
I (my OS does) calculate max cluster-## (needed for access-checks)
512*[sectors per FAT]/[nibbles per entry] rounded down by AND FFFFFFF4
it seem there is a gap between max FAT12 and min FAT16 because of
geometry vs. xxx4 limit issues. same for max FAT16 and min FAT32
cluster-size.
If I use that calculation, the standard 3.5" 1.4MB floppy format would be
seen as incorrect because it has a total clusters of 2847. It's not evenly
divisible by 4.
2847(dec) = 0B1F(hex). If zero means "no sector", it perfectly fits.


Greetings from Augsburg

Bernhard Schornak
James Harris
2021-04-13 09:57:56 UTC
Permalink
Post by Bernhard Schornak
Post by JJ
Post by wolfgang kern
I (my OS does) calculate max cluster-## (needed for access-checks)
    512*[sectors per FAT]/[nibbles per entry] rounded down by AND
FFFFFFF4
it seem there is a gap between max FAT12 and min FAT16 because of
geometry vs. xxx4 limit issues. same for max FAT16 and min FAT32
cluster-size.
If I use that calculation, the standard 3.5" 1.4MB floppy format would be
seen as incorrect because it has a total clusters of 2847. It's not evenly
divisible by 4.
2847(dec) = 0B1F(hex). If zero means "no sector", it perfectly fits.
I've lost track of what the above is discussing but in case it's of
interest to anyone I've mocked up a spreadsheet to calculate the key
'count of clusters' figure for different FAT geometry settings. Here is
the spreadsheet as a CSV:

"BPB Entry",
"BPB_BytsPerSec",512
"BPB_FATSz16",9
"BPB_FATSz32",
"BPB_NumFATs",2
"BPB_ResvdSecCnt",1
"BPB_RootEntCnt",224
"BPB_SecPerClus",1
"BPB_TotSec16",2880
"BPB_TotSec32",
,
,
"Derived data",
"Volume size in K","=B9*B2 / 1024"
"RootDirSectors","= INT(((B7 * 32) + (B2 - 1)) / B2)"
"FATSz","= IF(B3 <> 0, B3, B4)"
"TotSec","= IF(B9 <> 0, B9, B10)"
"DataSec","= B17 - (B6 + (B5 * B16) + B15)"
"CountofClusters","= INT(B18 / B8)"
"FAT type","= IF(B19 < 4085, ""FAT12"", IF(B19 < 65525, ""FAT16"",
""FAT32""))"

To use it load it in to a spreadsheet program (it loads successfully
into LibreOffice Calc and will hopefully work with others too), adjust
the BPB numbers at the top and it will calculate the derived data at the
bottom. Formulae taken (hopefully correctly) from fatgen103 pp 14-15.

The preloaded figures are for a 1.44MB floppy.
--
James Harris
Bernhard Schornak
2021-04-13 14:38:30 UTC
Permalink
Post by Bernhard Schornak
Post by JJ
Post by wolfgang kern
I (my OS does) calculate max cluster-## (needed for access-checks)
    512*[sectors per FAT]/[nibbles per entry] rounded down by AND FFFFFFF4
it seem there is a gap between max FAT12 and min FAT16 because of
geometry vs. xxx4 limit issues. same for max FAT16 and min FAT32
cluster-size.
If I use that calculation, the standard 3.5" 1.4MB floppy format would be
seen as incorrect because it has a total clusters of 2847. It's not evenly
divisible by 4.
2847(dec) = 0B1F(hex). If zero means "no sector", it perfectly fits.
I've lost track of what the above is discussing but in case it's of interest to anyone I've mocked
up a spreadsheet to calculate the key 'count of clusters' figure for different FAT geometry
"BPB Entry",
"BPB_BytsPerSec",512
"BPB_FATSz16",9
"BPB_FATSz32",
"BPB_NumFATs",2
"BPB_ResvdSecCnt",1
"BPB_RootEntCnt",224
"BPB_SecPerClus",1
"BPB_TotSec16",2880
"BPB_TotSec32",
,
,
"Derived data",
"Volume size in K","=B9*B2 / 1024"
"RootDirSectors","= INT(((B7 * 32) + (B2 - 1)) / B2)"
"FATSz","= IF(B3 <> 0, B3, B4)"
"TotSec","= IF(B9 <> 0, B9, B10)"
"DataSec","= B17 - (B6 + (B5 * B16) + B15)"
"CountofClusters","= INT(B18 / B8)"
"FAT type","= IF(B19 < 4085, ""FAT12"", IF(B19 < 65525, ""FAT16"", ""FAT32""))"
To use it load it in to a spreadsheet program (it loads successfully into LibreOffice Calc and will
hopefully work with others too), adjust the BPB numbers at the top and it will calculate the derived
data at the bottom. Formulae taken (hopefully correctly) from fatgen103 pp 14-15.
The preloaded figures are for a 1.44MB floppy.
Never spent time with filesystems (I developed some basics for IDEOS,
my 64 bit OS, but it never will be finished...). I just saw that 2848
is divisible by 16, so I thought it might be helpful to mention it.

If we shift the sector count two bit to the right, it does not matter
by what the number is divisible, anyway...


Greetings from Augsburg

Bernhard Schornak
wolfgang kern
2021-04-13 07:29:46 UTC
Permalink
Post by JJ
Post by wolfgang kern
I (my OS does) calculate max cluster-## (needed for access-checks)
512*[sectors per FAT]/[nibbles per entry] rounded down by AND FFFFFFF4
it seem there is a gap between max FAT12 and min FAT16 because of
geometry vs. xxx4 limit issues. same for max FAT16 and min FAT32
cluster-size.
If I use that calculation, the standard 3.5" 1.4MB floppy format would be
seen as incorrect because it has a total clusters of 2847. It's not evenly
divisible by 4.
2847 would be is dividable by 3 :) but 2848 (include Zero) is fine.
__
wolfgang

4.4 Other points to note
 The last sector of the FAT is not necessarily all part of the FAT. The
FAT stops at the cluster
number in the last FAT sector that corresponds to the entry for cluster
number
(CountOfClusters + 1), and this entry is not necessarily at the end of
the last FAT sector.
FAT implementations must not make any assumptions about what the
contents of the last
FAT sector are after the (CountOfClusters + 1) FAT entry. When
initializing (formatting)
a volume, the implementation must zero all bytes after this last FAT entry.
 The number of sectors reserved for each FAT (count of sectors in the
BPB_FATSz16 or
BPB_FATSz32 fields) may be bigger than the actual number of sectors
required for
containing the entire FAT. Therefore, there may be totally unused FAT
sectors at the end of
each FAT in the FAT region of the volume. Each implementation must
determine the value
for the last valid sector in the FAT using CountOfClusters (the last
valid sector in the FAT
is the one containing the FAT entry numbered CountOfClusters + 1).
JJ
2021-04-13 09:07:41 UTC
Permalink
Post by wolfgang kern
Post by JJ
Post by wolfgang kern
I (my OS does) calculate max cluster-## (needed for access-checks)
512*[sectors per FAT]/[nibbles per entry] rounded down by AND FFFFFFF4
it seem there is a gap between max FAT12 and min FAT16 because of
geometry vs. xxx4 limit issues. same for max FAT16 and min FAT32
cluster-size.
If I use that calculation, the standard 3.5" 1.4MB floppy format would be
seen as incorrect because it has a total clusters of 2847. It's not evenly
divisible by 4.
2847 would be is dividable by 3 :) but 2848 (include Zero) is fine.
But your calculation use `AND FFFFFFF4` or if it's a typo, an `AND
FFFFFFFC`.
wolfgang kern
2021-04-14 19:57:12 UTC
Permalink
Post by JJ
Post by wolfgang kern
Post by JJ
Post by wolfgang kern
I (my OS does) calculate max cluster-## (needed for access-checks)
512*[sectors per FAT]/[nibbles per entry] rounded down by AND FFFFFFF4
it seem there is a gap between max FAT12 and min FAT16 because of
geometry vs. xxx4 limit issues. same for max FAT16 and min FAT32
cluster-size.
If I use that calculation, the standard 3.5" 1.4MB floppy format would be
seen as incorrect because it has a total clusters of 2847. It's not evenly
divisible by 4.
2847 would be is dividable by 3 :) but 2848 (include Zero) is fine.
But your calculation use `AND FFFFFFF4` or if it's a typo, an `AND
FFFFFFFC`.
yeah you got me, it means minus 4.
__
wolfgang

James Harris
2021-04-13 09:42:17 UTC
Permalink
Post by JJ
Post by wolfgang kern
yes, we better stick to "count of clusters" for determination even some
handmade formatting variants may fail on this.
* 2nd byte of the VBR is 3A,3C,3E or >=5c. it may give a hint to format
* consecutive FAT-entry checks (like you did manually)
* root size limit could be an indication too.
The maximum cluster size for FAT16 is still confusing, though. At least for
me.
https://en.wikipedia.org/wiki/File_Allocation_Table#Initial_FAT16
In "Initial FAT16" section, it states that the maximum clusters is 65524.
However, in the "FAT16" right side floating section, it says 65536 which is
incorrect because cluster number 0x0000, 0x0001, and 0xFFF0-0xFFFF, are not
for data cluster numbers. Theorically, the maximum is 65536 minus 18, or
65518.
As I read fatgen103 the potential cluster index ids for FAT16 are

0000 - Unused and all ones except for media byte
0001 - An/the (not sure which) EOC mark and flag bits
FFF7 - To indicate a bad cluster
FFF8 and above - To indicate EOC (end of clusterchain)

That leaves 0002...FFF6 for data clusters.

IOW the number of usable cluster indices would be 65536 - 9 - 2 or 65525.

The document says that the maximum cluster index is one more than the
count of clusters. That would make the highest possible count of
clusters 65524 - which is the same as the number explicitly stated
elsewhere in the document.

IOW it looks as though you need to add FFF0 to FFF6 inclusive to your
calculations.
Post by JJ
In below archived Windows XP Resource Kit article: (long URL warning)
<https://web.archive.org/web/20060307082555/http://www.microsoft.com/technet/prodtechnol/winxppro/reskit/c13621675.mspx#EACBIAA>
In "Maximum Sizes on FAT16 Volumes" section, it also states that the maximum
is 65524. But this value is also beyond the theorical limit above.
No, it's correct. See above.
Post by JJ
Adding to the confusion, in "Maximum Sizes on FAT32 Volumes" section, it
states that the minimum cluster number is 65527. So if that's the case, what
happen to FAT file systems if they end up having 65525 to 65526? Should it
be FAT16, FAT32, or shouldn't exist at all?
If the count of clusters is 65525 or above then it's a FAT32 volume,
according to fatgen103. When the XP document mentions 65527 could it be
including the two unusable clusters 0 and 1? If so then the numbers
would be consistent.
--
James Harris
JJ
2021-04-08 00:09:23 UTC
Permalink
Post by James Harris
On the contrary, I've just mounted your image as A: and written a
multi-cluster file to it. The resulting FAT shows
f0 ff ff ff ff ff ff 6f 00 07 80 00 09 a0 00 0b
c0 00 0d f0 ff 00 00 00 00 00 00 00 00 00 00 00
The first 8 bytes are what were there before but note what follows. In
00 07 80 00 09 a0 00 0b
those FAT entries are clearly 12-bit, not 16-bit.
IOW the "FAT16 " text at 0x36 is irrelevant to Microsoft. They still
treat the file as a FAT12 floppy image, not a FAT16 one.
You're right. The FAT entries are still 12 bits. I overlooked that.

It looks like the number of clusters determines whether it's treated as
FAT-12 or FAT-16.

If I handcraft it as 16-bit, the system sees it as corrupted file system,
and CHKDSK /F will fix the 16-bit FAT to 12-bit FAT.
James Harris
2021-04-08 10:52:19 UTC
Permalink
Post by JJ
Post by James Harris
On the contrary, I've just mounted your image as A: and written a
multi-cluster file to it. The resulting FAT shows
f0 ff ff ff ff ff ff 6f 00 07 80 00 09 a0 00 0b
c0 00 0d f0 ff 00 00 00 00 00 00 00 00 00 00 00
The first 8 bytes are what were there before but note what follows. In
00 07 80 00 09 a0 00 0b
those FAT entries are clearly 12-bit, not 16-bit.
IOW the "FAT16 " text at 0x36 is irrelevant to Microsoft. They still
treat the file as a FAT12 floppy image, not a FAT16 one.
You're right. The FAT entries are still 12 bits. I overlooked that.
It looks like the number of clusters determines whether it's treated as
FAT-12 or FAT-16.
If I handcraft it as 16-bit, the system sees it as corrupted file system,
and CHKDSK /F will fix the 16-bit FAT to 12-bit FAT.
I found a surprising comment on Wikipedia about this indicating that
despite the presence of the BPB from MS-DOS 2.0: "Versions of DOS before
3.2 totally or partially relied on the media descriptor byte in the BPB
or the FAT ID byte in cluster 0 of the first FAT in order to determine
FAT12 diskette formats even if a BPB is present."

Also: "Depending on the FAT ID found and the drive type detected they
default to use one of the following BPB prototypes instead of using the
values actually stored in the BPB."

https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#FATID

That includes a large table of media type codes against meanings.
--
James Harris
JJ
2020-10-04 22:55:06 UTC
Permalink
Post by ***@gmail.com
What is the proper way to determine whether the
FAT boot sector is FAT 12/16 or FAT 32?
I could look at offset 0x36 for "FAT1" but that
offset is marked "reserved" in FAT32, so could
technically be anything.
Thanks. Paul.
IME so far... only FAT12 disks may have its File System field value as other
than `FAT12`. They're usually found in old floppy disks, floppy disks for
non IBM PC or compatible machines, and disks embedded in other devices.

For most file systems, its File System field is used for identification. For
file system which don't have any File System field, they have other field(s)
as identification. The identifications field(s) varies across different file
systems, so you'll have to check different field offset for each of them.
You can not use a single field offset as a catch all detection.
Loading...