Take a look at FAT 12 table acess code. Why it uses section_size and other FAT's uses sector_size? And current_cluster and active_cluster, article uses it interchangeably. And data_sectors equation can be used only in FAT12/16 ,first_data_sector too. It uses only table_size_16 and total_sectors_16. --Kubawal 02:56, 5 February 2015 (CST)
Fixed it and some other bugs --Kubawal 6:52, 9 February 2015 (CST)
take a look at the hex analysis of the bootsector. PLAIN UGLY. someone know how to fix that without breaking the monospaced font? - Combuster 09:00, 6 December 2006 (CST)
How's that? -Jhawthorn 00:33, 7 December 2006 (CST)
Nice work - Combuster 04:41, 7 December 2006 (CST)
The section "File Allocation Table Entry Cluster Values" Is plainly rediculous... It seems like almost a joke on the reader? I mean stuff like
"AND the binary value of the hexadecimal number of 8007 (1000 0000 0000 0111) to the binary value of the hexadecimal number 0FFF (0000 1111 1111 1111). The result is **7 (hex or decimal). "
It goes back and forth about hex vs decimal vs binary.... A number is a number, no matter what base it's in... the whole section just seems like it's made to be as confusing as possible... or is it just me? I'm not trying to be critical but it does seem to be done that way on purpose. I'll try to rewrite that section if I can obtain the correct knowledge somewhere. ---Posted by Dkelly.
Please sign your posts Dkelly! --Brynet-Inc 07:10, 10 November 2007 (CST)
I've cleaned it up a lot. No more crazy hex->decimal or decimal->hex conversions. Nicer flow etc. If you miss something from the old page be sure to mention it (or add it back in yourself :) ). Stevo14 09:21, 5 July 2008 (UTC)
Calculations regarding the size of the root directory was completely missing. I added it in because the calculation were important for FAT12/16. Also, I could not find anything that talks about "relative" and "absolute" clusters in the hardware white paper (version 1.03 December 6, 2000, Microsoft). -7 July 2008 by uglyoldbob
By relative and absolute I meant cluster numbers measured from the beginning of the free space or the beginning of the volume. AFAIK, all of the cluster numbers that you read out of the directories are relative to the start of the free space, not the start of the volume. Stevo14 12:03, 7 July 2008 (UTC)
There seems to be some contradiction concerning the extended boot record for fat32: Offset/Length/Description
|36||4||The size of the File Allocation Table in bytes.|
|42||1||Signature (must be 0x28 or 0x29).|
|39||2||FAT version number.|
Am I right in assuming that the signature needs to be removed (it exists twice in the table) and the offset for the fat version number need to be changed to 42? Furthermore, the fat size is written as being in bytes, while wikipedia claims that offset 0x24/36d ist "Sectors per file allocation table". Does someone know which is right? Narida 15:16, 11 August 2009 (UTC)
A certain document from a certain source tells me that at offset 40 is an 'extended flags' field of 2 bytes, followed by a 'filesystem version' field of 2 bytes. So, I believe you are correct in that the signature field should be removed there, and that the offset of the 'filesystem version' field should be changed to 42.
bughunter2 20:50, 11 August 2009 (UTC)
I'm not sure, but it might be interesting to add information regarding exFAT to the topic. Since it's Microsoft's "replacement for FAT" after all. I don't know too much about all these file systems, so I'm just dropping in idea's here. --Creature 10:43, 21 December 2009 (UTC)
Long file names
US patent 5579517 A expired in 2015 therefore I have removed references to LFN being patented John 16:45, 18 November 2016 (CST)