Talk:File Allocation Table/Archive 1

message: I'm confused about the naming of the FAT versions.
Isn't the number after FAT just the size of the FAT entries?
VFAT can be used with FAT12, FAT16 or FAT32 but aren't they basically all the same?
-->>VFAT is simply the name of a driver in Windows, the article was incorrect when it associated that with a particular file system layout. I have removed that line. 67.168.183.122
----
FAT12 uses 12-bit entries, while FAT16 uses 16-bit entries.  FAT32 indeed uses 32-bit entries, but is also a redesign, and is incompatible with prior versions.
There is MUCH that could be added here.  How much detail is wanted?
--Scott. 08:02, 2004 Feb 9 (UTC)
The article mentions:  This initial version of FAT is now referred to as FAT12.
This is known as a retronym.
http://en.wikipedia.org/wiki/Retronym  —Preceding unsigned comment added by Ericbirecki (talk • contribs) 16:35, August 24, 2007 (UTC) 
This was actually confusing for me the first I read it and I don't believe the article is complete on this matter. I've read somewhere (I can look that up again) that VFAT is the modification made to FAT16 to support long file names and that FAT32 already incorporate them. Therefore you can have FAT16 (which uses 8.3 filenames), VFAT (which can be 16 or 32 bits) and FAT32 (which is the same thing as VFAT 32 bits, since it WILL support long file names).
--Franciozzy (talk) 20:43, 17 November 2008 (UTC)
thread_title:  Naming of FAT versions 

message: i believe dos 2.x could not address up to 32 mb but only 10 mb officially and 15 mb unofficially.
but fairly sure it could from dos 3.x onwards.
did the fat change then ?
:I've changed the first para of the history section. The initial version of MS-Dos didn't support directories, but MS-Dos 2.x and 3.x did while still using Fat12 as the filesystem. Perhaps some change was made to Fat12 for MS-Dos 2.
:Also, the filesystem size limit for Fat12 is 32 MB. 12 bits for each FAT entry which can distinguish 4096 different clusters. It may be that MS-Dos 1 only used a 512 byte cluster size, but later versions of MS-Dos support cluster sizes up to 8 kb. It's possible that dos 2.x supported something in between, so the comment above this might be correct. There were also variants of MS-Dos 3.x which supported disk partitions larger than 32 MB. I'm not sure whether they did this by increasing the cluster size further. Fat16 allowed larger cluster sizes but wasn't introduced until MS-Dos 4. -gadfium 23:50, 6 Dec 2004 (UTC)
replies: text: Is it true that FAT originally had only a flat directory hierarchy, and only later were nested subdirectories supported? If true this distinction should be noted. --Bk0 03:23, 7 Dec 2004 (UTC)

text: The first version of MS-Dos, ie version 1, did not support subdirectories (and no version of MS-Dos supported the CP/M equivalent of user areas). The concept of subdirectories was well established by that time (eg in Unix), but perhaps they weren't considered necessary for such small machines. Although I've been involved with computers for a very long time, I've never actually seen version 1 of MS-Dos running. I presume that MS-Dos 1 supported some file attributes (which include read-only, hidden, system, archive in later versions), so an unused attribute bit was used for directories in MS-Dos 2 and later. Long file names use a previously-ignored combination of attribute bits which allow them to co-exist with 8.3 file names.-gadfium 04:37, 7 Dec 2004 (UTC)
thread_title:  fat and hard disk partitions 

message: The "reserved values" FAT entry values given are incorrect, at least when compared against the Microsoft Extensible Firmware Initiative specification. The maximum cluster count on FAT12 is 4084, giving a maximum allocatable cluster index of 4084+2-1 = 0xFF5 ("there is no such thing as a FAT12 volume that has more than 4084 clusters"); the maximum cluster count on FAT16 is 65524, giving a maximum allocatable cluster index of 65524+2-1 = 0xFFF5 ("there is no such thing as a FAT16 volume that has [...] more than 65524 clusters"); and for FAT32, all indexes up to and including 0x0FFFFFF6 are allocatable ("no FAT32 colume should ever be configured such that 0x0FFFFFF7 is an allocatable cluster number"). --Jkew 17:55, 18 October 2005 (UTC)
replies: text: Microsoft MS-DOS Programmer's Reference : version 5.0, , from Microsoft press, Microsoft's official reference manual to the MS-DOS operating system says: "(F)FF0h-(F)FF6h Reserved; do not use." Also the Microsoft Extensible Firmware Initiative specification states "..., it is highly recommended ... you should you avoid making volumes of any type that have close to 4,085 or 65,525 clusters. Stay at least 16 clusters on each side away from these cut-over cluster counts." A bit broad, but clearly you can not use them. I would also speculate, that the reasoning behind the reservation is that any utility trying to read the first cluster of empty file, volume label, or the ".." directory just below root, will read the media ID byte at first byte of FAT giving values in range 0xFF0 to 0xFFF. If these are not valid clusters, then such buggy tools will at least stop early. Marko 17:43, 27 August 2007 (UTC)

text: I removed the dispute tag now that we have a Microsoft source for the reservation. I also clarified other parts. The value 1 is not mentioned in the reference manual. The reference also says "(F)FF7h Bad sector in cluster; do not use cluster.". So if anything should be used to reserve clusters for something, it is not 1, but this bad cluster mark.Marko 18:09, 27 August 2007 (UTC)

text: I agree, and have tagged dispute on the table and fact tagged the reserved row. Also changed EOF to EOC and replaced "character" by "entry" and other minor fixes. -32.58.34.227 12:31, 18 July 2007 (UTC)
thread_title:  differences to the "Microsoft Extensible Firmware Initiative"