OSDev.org

Hey,

Is there any way I can detect if a floppy disk contains a valid FAT12 file system? I've got drivers for FAT12 if it exists but who's to say it doesn't contain EXT2 or maybe even SFS? Since there's no partition table on a floppy disk, there's no way to tell.

There doesn't seem to be a field in the BPB that indicates whether the file system is FAT12. I've looked at the OSDev Wiki and there's the Volume Identifier String in the extended boot record but apparently that shouldn't be relied upon according to the file system specifications.

How can I detect the file system on the disk?

If you can detect that it's fat, 12/16/32 are detected by the size of the disk, clusters, and FAT.

m12 wrote:If you can detect that it's fat, 12/16/32 are detected by the size of the disk, clusters, and FAT.

The exact method is uncertain. However on a floppy disk I can say with reasonable certainty that it will be FAT12.

Prochamber wrote:The exact method is uncertain.

No, it's not. If there are 9810 (completely random number, not likely) clusters on the disk,
FAT12 will have a FAT size of 9810*1.5=14715 bytes=29 sectors per FAT
FAT16 will have a FAT size of 9810*2=19620=39 sectors per FAT
FAT32 will have a FAT size of 9810*4=39240=77 sectors per FAT

I think, but am not sure that these numbers are rounded up to a power of two, so 32 for FAT12, 64 for FAT16, and 128 for FAT32

FAT can be detected by examining various fields and verifying that they are all valid:
- Word at 0x1fe equals 0xaa55
- Sector size is a power of 2 between 512 and 4096
- Cluster size is a power of 2
- Media type is 0xf0 or greater or equal to 0xf8
- FAT size is not 0
- Number of sectors is not 0
- Number of root directory entries is 0 (FAT32) or not 0 (FAT12, FAT16)
- Root cluster is valid (FAT32)
- File system version is 0 (FAT32)

To detect FAT12, check that the number of clusters is less than 4085.

m12 wrote:If there are 9810 (completely random number, not likely) clusters on the disk,
FAT12 will have a FAT size of 9810*1.5=14715 bytes=29 sectors per FAT
FAT16 will have a FAT size of 9810*2=19620=39 sectors per FAT
FAT32 will have a FAT size of 9810*4=39240=77 sectors per FAT

I think, but am not sure that these numbers are rounded up to a power of two, so 32 for FAT12, 64 for FAT16, and 128 for FAT32

Comparing the number of clusters to the sectors per fat? That might work for different FAT types, but I'm working on floppy disk file systems so it will very likely be FAT12.

Gigasoft wrote:FAT can be detected by examining various fields and verifying that they are all valid:
- Word at 0x1fe equals 0xaa55
- Sector size is a power of 2 between 512 and 4096
- Cluster size is a power of 2
- Media type is 0xf0 or greater or equal to 0xf8
- FAT size is not 0
- Number of sectors is not 0
- Number of root directory entries is 0 (FAT32) or not 0 (FAT12, FAT16)
- Root cluster is valid (FAT32)
- File system version is 0 (FAT32)

To detect FAT12, check that the number of clusters is less than 4085.

Okay, so I just need more error testing. There are a lot of bailout conditions I could check, there are even more fields like 'number of FATs' that must be > 0. Some of them might seem valid by coincidence but the chance of all of them matching is not worth thinking about. I will leave the boot signature out, because that could be used by any bootable partition.

Thanks for your help m12 and Gigasoft!

Don't forget the fat signiture, which is either 0x29 or 0x28

No, it's not. If there are 9810 (completely random number, not likely) clusters on the disk,
FAT12 will have a FAT size of 9810*1.5=14715 bytes=29 sectors per FAT
FAT16 will have a FAT size of 9810*2=19620=39 sectors per FAT
FAT32 will have a FAT size of 9810*4=39240=77 sectors per FAT

I think, but am not sure that these numbers are rounded up to a power of two, so 32 for FAT12, 64 for FAT16, and 128 for FAT32

If there are 9810 clusters, it's FAT16, period. Anything between 4085 and 65524 clusters means FAT16. And the 29h signature doesn't have to be there, it merely indicates that additional fields are present.

Gigasoft wrote:

No, it's not. If there are 9810 (completely random number, not likely) clusters on the disk,
FAT12 will have a FAT size of 9810*1.5=14715 bytes=29 sectors per FAT
FAT16 will have a FAT size of 9810*2=19620=39 sectors per FAT
FAT32 will have a FAT size of 9810*4=39240=77 sectors per FAT

I think, but am not sure that these numbers are rounded up to a power of two, so 32 for FAT12, 64 for FAT16, and 128 for FAT32

If there are 9810 clusters, it's FAT16, period. Anything between 4085 and 65524 clusters means FAT16.

You mean if I have a 128 MB USB flash drive with 32768 clusters, it can't have FAT32 on it? Cause if so, I need to inform one of my teachers that hers isn't real.

m12 wrote:Don't forget the fat signiture, which is either 0x29 or 0x28

That would be useful. Is it just me or it FAT is just a poorly-designed file system? It would be so much easier to just format the disk in SFS but there aren't the tools to support it.

Gigasoft wrote:If there are 9810 clusters, it's FAT16, period. Anything between 4085 and 65524 clusters means FAT16. And the 29h signature doesn't have to be there, it merely indicates that additional fields are present.

For the FAT type, I think it would be better to compare the FAT size to the number of clusters rather than making any assumptions based on the size.

EDIT: Actually that won't work either, many FAT file systems have a FAT that is smaller than the sectors on the media.

Prochamber wrote:

m12 wrote:Don't forget the fat signiture, which is either 0x29 or 0x28

That would be useful. Is it just me or it FAT is just a poorly-designed file system?

It's made by microsoft, what did you expect?
That plus the fact that many of the fields the specification says not to rely on for any purpose.

Prochamber wrote:Is it just me or it FAT is just a poorly-designed file system?

It is, but it wasn't always this bad.

FAT's original implementation (sometimes known as FAT8, but often not known at all) was created by Marc McDonald and Bill Gates in 1977 for a product called Stand-Alone Disk BASIC-80 using an 8-bit file allocation table (clusters 0x02 through 0xBF) and 16-byte directory entries (32-byte entries under MIDAS, which shipped with a few other FAT improvements).

Then Tim Paterson got his hands on it and rewrote it with a 12-bit FAT (and some optimizations that made it incompatible with the 8-bit BASIC-80 filesystem like the 32-byte directory entries) for QDOS, which ended up becoming the first release of MS/PC-DOS. It became a standard as a result.

Of course, the issue with a filesystem that revolves around thousands of sequential packed 12-bit numbers is that a processor that can only natively deal with 8- and 16-bit numbers has a hell of a time working with it efficiently.

FAT16 is a hack to extend a hack filesystem that extends an old filesystem that was designed for 8-bit disk machines running BASIC.

VFAT's LFNs are a hack on top of that with a really poor design. On the other hand, Unicode. Kinda.

FAT32 is a hack on top of FAT16 that has VFAT as a side implementation ported to it.

FAT wasn't originally poorly designed. It just ended up being poorly designed in retrospect because it's the Inception of filesystem hacks.

Blacklight wrote:

Prochamber wrote:Is it just me or it FAT is just a poorly-designed file system?

FAT wasn't originally poorly designed. It just ended up being poorly designed in retrospect because it's the Inception of filesystem hacks.

So, really it's just like BIOS then; Originally a great idea that was popularized and implemented by heaps of people. Some of which were really bad at keeping to standards, which resulted in new standards being fairly broad and hard to work with.

There's a lot of silly things like using an uneven bit width and having a disk drive field on the disk that's like someone painting a map with a pointer to their current location on a city bus. The real problem seems to be people making solutions that don't scale and thinking that it'll all be replaced soon and no-one will notice. Like segments.

Anyway, lets not dwell on the negative aspects of the modern PC. I'll do more error checking and assume the file system on a floppy disk is FAT12 if all the fields match. If I want to detect other types of file systems I can just check their signatures. If I eventually have drivers for a hard drive I can use the partition table to detect their type.

Thanks for your help everyone!

m12 wrote:You mean if I have a 128 MB USB flash drive with 32768 clusters, it can't have FAT32 on it? Cause if so, I need to inform one of my teachers that hers isn't real.

That's correct. And it would also have an invalid cluster size of 65536. This will most certainly be unreadable in Windows which will at best treat it as FAT16. On the other hand, if the cluster size was 32768, then the number of clusters would exceed 65524 and you'd have FAT32. Your teacher should read the specification again carefully.

ProChamber wrote:For the FAT type, I think it would be better to compare the FAT size to the number of clusters rather than making any assumptions based on the size.

The number of clusters is the only thing that determines FAT type.
0 - 4084 => FAT12
4085 - 65524 => FAT16
65525 and up => FAT32

Any volume that violates this is simply messed up and will not be usable in other operating systems.

Gigasoft wrote:

m12 wrote:You mean if I have a 128 MB USB flash drive with 32768 clusters, it can't have FAT32 on it? Cause if so, I need to inform one of my teachers that hers isn't real.

That's correct. And it would also have an invalid cluster size of 65536. This will most certainly be unreadable in Windows which will at best treat it as FAT16. On the other hand, if the cluster size was 32768, then the number of clusters would exceed 65524 and you'd have FAT32. Your teacher should read the specification again carefully.

I doubt she ever has. I'm just saying that she has a 128MB flash drive that windows shows as fat32

EDIT:
My point is, it can't be fully based on the # of clusters. If somebody decides to format it as something higher, it's formatted higher.