Talk:File Allocation Table

From Wikipedia, the free encyclopedia

FAT+

Enhanced DR-DOS implements FAT+, which supports filesystems up to 256GB and native LFN support. It should be mentioned.

Error report

In doing research for a new book, I encountered this File Allocation Table article, and wanted to point out what I believe are several factual errors contained therein. As I can see this article has some history behind it, I'll leave it to those more heavily invested in maintaining and updating this article to look over and verify what I have posted here, and to implement any changes as are deemed appropriate. Thanks for listening:

1.) FAT (FAT12) was originally developed for stand-alone disk BASIC (not MS-DOS). See reference below.

2.) FAT (FAT12) was developed by Microsoft, specifically by Bill Gates and Marc McDonald (not Seattle Computer Products). See reference below.

3.) FAT (FAT12) was developed in 1976 and first made its debut in 1977 with the release of stand-alone disk BASIC-80 for NCR (not in August 1980 with QDOS). See reference below.

4.) FAT16 was first introduced on August 14, 1984 in IBM PC DOS 3.0 (same day as the '286 processor-based IBM PC AT). Reference: IBM PC DOS 3.0 announcement letter, and the IBM PC DOS Technical Reference, First Edition p/n 6024181, dated February 1985.

Historical details:

FAT (FAT12) was apparently "created" by Bill Gates and developed by Marc McDonald. Marc is considered to be the 1st MS employee (after founders Bill Gates and Paul Allen). FAT was originally developed for use in stand-alone disk BASIC in 1976, which pre-dated MS-DOS by several years. Marc can be seen talking about FAT about halfway through the video here:

http://channel9.msdn.com/showpost.aspx?postid=111590

According to Marc, FAT was created in 1976 for stand-alone BASIC-80 on 8" floppies. In 1978 MS ported BASIC-80 to the x86, however they had used an emulator and had no actual x86 hardware to test it on. In 1979 Tim Paterson called MS asking if they had any x86 software, and MS was interested in working with Tim because he (and Seattle Computer) had the first working x86 system they knew about. Then in 1980 Tim "borrowed" FAT for QDOS, which became SCP 86-DOS, which became MS-DOS.

Other information and references:

According to an article on HPFS by Ray Duncan in the Sept. 1989 (Vol4 NO5) issue of the Microsoft Systems Journal, Ray states that "The FAT was invented by Bill Gates and Marc McDonald in 1977 as a method of managing disk space in the NCR version of standalone Microsoft Disk BASIC. Tim Paterson, at that time an employee of Seattle Computer Products (SCP) was introduced to the FAT concept when his company shared a booth with Microsoft at the National Computer Conference in 1979. Paterson subsequently incorporated FATs into the file system of 86-DOS, an operating system for SCP's S-100 bus 8086 CPU boards."

Microsoft also states that Bill Gates created the initial version of FAT on its site here:

FAT File System: The Story Behind the Innovation
http://www.microsoft.com/mscorp/ip/tech/fathist.asp

"The FAT file system was one of the first technologies developed by Microsoft. In 1976, Bill Gates created the initial version of FAT during a short hotel stay in Albuquerque, N.M. Intel incorporated FAT technology in an operating system it developed for the Intel 8086 chip. Microsoft purchased the rights to this system and then recoded the FAT file system as part of the first version of the Microsoft MS-DOS operating system."

I believe the reference to an Intel OS is for iRMX 86, which may have been the first operating system to use FAT, even before QDOS. A reference is here:

http://www.8052.com/forum/read.phtml?id=60202

While the specifics of what Bill and Marc contributed are somewhat fuzzy, it seems clear that both were involved, and that Tim Paterson saw the FAT in stand-alone BASIC-86, which he then incorporated into QDOS.

Paterson confirms some details on the origins of FAT in the Softalk article on his site here:

http://www.patersontech.com/Dos/Softalk/Softalk.html

The article states: "Paterson created QDOS's file management module using the same method found in standalone Basic-86."

The following excerpt is even more enlightening. It was written by Tim Paterson and is taken verbatim from the book "inside out: Microsoft-In our own words" ISBN 0-446-52739-4, published in September 2000:

---Start of excerpted text---

Tim Paterson, former software design engineer, Visual Studio

We gave Microsoft a call and asked if they had any 16-bit software for our customers to use, since none of the existing 8-bit software would run on my 8086 board. They were very interested in working with us because I guess we had the first 8086 working hardware around. They said they had their 8086 Stand-Alone BASIC ready to try.

So I went up there with our Cromemco Z-2 box, fired it up, and actually got BASIC up pretty quickly. Bob 0'Rear and I had it working in about a week: it was pretty amazing. Remember that Stand-Alone BASIC doesn't need an operating system: it can save files and stuff, but no applications can run under it. To make SCP's computer system truly useful for other software development, it was clear to all of us that we needed an operating system.

Everyone thought Digital Research would fill the gap - that they would come out with a 16-bit version of their CP/M operating system. But Digital Research was behind. After more than six months of waiting, I decide to do it myself. I started to work on a "quick and dirty" operating system (QDOS) that would bridge the gap for SCP's machine.

I set out to make my operating system as compatible as possible with CP/M because it was an industry standard. And compatibility would make it easier for software developers to write applications for both. I also wanted QDOS to be fast and efficient, so I borrowed Microsoft's approach to file allocation from their BASIC so that loading and saving files on disk wouldn't become the bottleneck I thought it was with CP/M.

Once QDOS was up and running, we again called Microsoft to ask them about getting their software, such as BASIC and Pascal, to run under it. Little did I know, Microsoft had just started talks with IBM about providing all the software for its first PC, which was based on the 8088 chip, a lower-cost follow-on to the 8086. IBM was not making headway with Digital Research on getting CP/M-86 for their new machine and asked Microsoft to provide an operating system for them. Microsoft told us that my operating system met the needs of a major OEM customer of theirs, which would go unnamed.

Seattle Computer licensed Microsoft as a sales agent for QDOS, which we had by then renamed SCP 86-DOS. Meanwhile, SCP decided to quit trying to sell through retail stores and focus on mail order instead. I didn't agree with the strategy, so I called Paul Allen at Microsoft and asked for a job. He said, "Sure."

Two months after I joined Microsoft - and just one month before IBM announced its first PC - Microsoft offered to buy 86-DOS from Seattle Computer. As an employee of Microsoft and shareholder of Seattle Computer, I was brought in as the sale agreement was being finalized - maybe to provide an opinion that the deal was fair for both sides. After that, I worked on the first version of MS-DOS that shipped to customers other than IBM: version 1.25. I haven't worked on MS-DOS since. I've spent the rest of my Microsoft career working on programming tools, mostly Visual Basic. But I take pride in the fact that the program I wrote, with the added efforts of many others over the years, became, at its peak, the most widely used computer program in the world.

---End of excerpted text---

FAT16 introduction and historical information:

FAT16 debuted in IBM PC DOS 3.0, but was limited in support to a single 32MiB volume per drive due to the lack of support for extended DOS partitions and the use of 16-bit sector numbers internally and in the VBR (Volume Boot Record).

In April 1987 PC DOS 3.3 introduced the extended partition, allowing support for up to 23 total volumes of up to 32MiB each.

Microsoft had OEM DOS deals with IBM and Compaq, and Compaq introduced Compaq DOS 3.31 in November 1987. Compaq DOS 3.31 was the first version of MS-DOS to use 32-bit sector addressing internally and in the VBR (Volume Boot Record).

The rest of the PC community followed suit in July 1988, when IBM released PC DOS 4.0 and Microsoft released the MS-DOS 4.0 packaged product (a generic version for system builders) at the same time. The use of 32-bit sector addressing meant that FAT16 could now handle partition sizes up to 2GiB using 64 sectors per cluster.

FAT16 has remained largely unchanged since the debut of DOS 4.0, with perhaps one exception. Windows NT/2000/XP can optionally create or support FAT16 volumes that use 128 sectors per cluster (64KiB), bringing the maximum FAT16 volume size to 4GiB. However, any volumes formatted in that manner are not readable in virtually any other OS, and 64KiB clusters also cause many disk utilities to fail. For maximum compatibility, FAT16 volumes under NT/2000/XP should be limited to using 32KiB clusters and a 2GiB max. volume size.

I hope those of you involved with updating and maintaining this article find this information useful. Thanks, Scott Mueller http://www.upgradingandrepairingpcs.com or scottmueller (at) compuserve (dot) com.

1.) FAT (FAT12) was originally developed for stand-alone disk BASIC (not MS-DOS). See reference below.

I cannot find any reference that it first implementation was before QDOS, can you provide URL?

Cannot find that documents, can you provide them please?

—Claunia 12:56, 14 September 2005 (UTC)

Neutrality

I removed this

FAT is a relatively early file system design that was designed in a hurry to replace the CP/M file system - it was in fact the main innovation in the earlier versions of MS-DOS compared to CP/M, otherwise DOS was almost a clone of CP/M. FAT's designers did not even exploit what was already known about file system design, and because of that, it suffered from several problems. First, its simple file layout allows for easy fragmentation, which leads to significant slowdowns during file system operations. Secondly, FAT was not designed for redundancy in the case of system failure. Thirdly, the first versions of FAT allowed file name sizes of only up to 11 characters (file name of 8 and a file extension of 3), although a work-around was developed when Microsoft implemented VFAT, that would allow file names of up to 255 characters. Finally, the large cluster size in many versions of FAT meant that a lot of space was being wasted on padding small files to the cluster size.

However, because IBM designated MS-DOS as its primary operating system for its PC, and MS-DOS used FAT, FAT became widely used and is still used in a number of circumstances. Because of the primitive design, it is easy to create a basic FAT implementation, and because of the ubiquity of MS-DOS and Windows, FAT has become useful in providing a base level of interoperability in some circumstances.

because overall the tone is not neutral, makes incorrect statements, and is overall not useful. The history below this makes a lot more sense and covers the facts better. And yes I am a coauthor of MSDOS and the FAT32 file system as well; hard to prove identity on internet, anyway you never heard of me so what good would that do. 67.168.183.122

If you have no way of proving your identity then stop using it as the basis for your edits. Which parts of those paragraphs are non neutral, incorrect or not useful? Was FAT not subject to fragmentation? Was it not used by MS-DOS? Is it not "easy to create a basic FAT implementation"? Outline the parts you disagree with don't just delete the paragraphs wholesome. Also if you registered an account and signed your posts with ~~~~ that would help. AlistairMcMillan 10:45, 21 Sep 2004 (UTC)

gah my explanation was deleted on your last post! anyway, the text is non-neutral with comments such as "designed in a hurry", "main innovation","did not even exploit", et al. All of this is biased and inccorect. Facts are wrong two, such as claiming no redundancy which FAT does indeed have; the concept of fragmentation causing a problem is not that big a problem with the original FAT, and fragmentation exists in all file systems anyway; the reference to cluster size is a red herring and doesnt mean anything really. Basically, these paragraphs provide no useful information but ignorantly sniping at decisions made by engineers many years ago. The history section below the header is sufficient. 67.168.183.122

Your claim that your explanation was deleted isn't backed up by the edit history of this page. You are aware that all edits are recorded, right? Please explain what redundancy FAT has? Two copies of the FAT table? Is that what you are talking about? Fragmentation is a big problem with FAT filesystems and to my knowledge while other filesystems have fragmentation, no other filesystem has as large a problem with it as FAT. The comment about cluster size needs to be better explained it is too ambiguous as it stands, however it is an issue with FAT filesystems.

These paragraphs could be a lot better written and do show some bias, but they are not non-factual and would be better re-written, not deleted. AlistairMcMillan 11:00, 21 Sep 2004 (UTC)

BTW About your VFAT edit. What is a DELFN? When was it introduced? What is the name of the filesystem that introduced it? AlistairMcMillan 11:10, 21 Sep 2004 (UTC)

IMHO language in those two paragraphs is somewhat biased and overstated. But it is basically factual and deserves rewriting rather than deletion. For example, it would be better to state that the original name of the OS was "QDOS," for "Quick and Dirty OS," and cite the actual timeline of the development, and let the reader decide whether it was "designed in a hurry." I think it's reasonable that if Microsoft had not been in a hurry, they would have written an OS themselves rather than purchasing QDOS from Tim Paterson. The statement "DOS was almost a clone of CP/M" is an exaggeration. IIRC, though, Microsoft has acknowledged that there was some actual "low-level borrowing" (i.e. actual incorporation of binary code) from CP/M in the first release of MS-DOS, in one of the file system APIs. IIRC the use of these API calls was deprecated from the start and the code itself was eventually removed. I certainly wouldn't put any of this in the article until and unless I can find references to back this up, though. I think it is NPOV to say that FAT was technically unsophisticated, in comparison to minicomputer and mainframe OS file systems, at the time it was introduced; that it was derived from CP/M's file system (again, I think Microsoft acknowledges this somewhere, probably in the MS-DOS encyclopedia); and that whether or not it is patentable, it is not regarded within the technical community as being significantly original or innovative. [[User:Dpbsmith|Dpbsmith (talk)]] 14:36, 21 Sep 2004 (UTC)

67.168.183.122 23:03, 21 Sep 2004 (UTC) Come on guy, go read what you put in there. The whole first new paragraph says not one thing about the FAT file system, but instead defends some position about the history of MSDOS. These statements are not neutral, but actually an attack. I am going to ask you to show some character, and do not put that stuff back in. The history of FAT is discussed in the history section of the article already.

As an aside, please recall that DOS booted in only 16k of RAM, off a 360k floppy, no harddrive, and still had space for programs! [the memory print for a mouse cursor today is larger than all of MSDOS] So it is not constructive to comment how stupid the file system was, or what the features it lacked compared to modern systems. It is impressive for what it did do, not a failure what it did not do!

67.168.183.122 23:03, 21 Sep 2004 (UTC)

What this guy did was to take an existing paragraph that had some POV problems and add some supporting material justifying it from a more neutral point of view. I appreciate what you're saying and am not reverting the change. Nevertheless, in understanding FAT, and, yes, the licensing controversy, I strongly disagree that it was "impressive for that it did do." All of the minicomputer OSes of the day needed to achieve pretty much the same things in comparable amounts of RAM, and most of them managed to do it better than the comparable microcomputer OSes did. The Apple DOS 3.3 file system was worse that FAT, of course. Just as with literary articles, I think it is entirely appropriate that computer articles include justified, neutral, well-backed critical appraisals of the technology along with descriptions of the technology itself.

I'm not sure how much of this really does belong in the article or where it should go, but I'm not convinced that it should be removed entirely. Therefore, I'm putting it here. This is the material that was removed.

FAT is a relatively unsophisticated file system design. Tim Paterson, the original developer, has written that "The first versions of the operating system, called QDOS 0.10, were shipped in August 1980. QDOS stood for Quick and Dirty Operating System because it was thrown together in such a hurry (two man-months)." Microsoft purchased the rights and released the system as MS-DOS in July 1981. FAT was a replacement for the CP/M file system—it was in fact the main innovation in the earlier versions of MS-DOS compared to CP/M. In his book Accidental Empires, Robert X. Cringely characterized QDOS as "a 16 bit clone of CP/M... Paterson admitted to a little "low-level" borrowing from CP/M, too, but claimed that most of the code was his own. Gary Kildall still thinks a lot of QDOS code was stolen straight from his CP/M."

FAT's designers did not even exploit what was already known about file system design, and because of that, it suffered from several problems. First, its simple file layout allows for easy fragmentation, which leads to significant slowdowns during file system operations. Secondly, FAT was not designed for redundancy in the case of system failure. Thirdly, the first versions of FAT allowed file name sizes of only up to 11 characters (file name of 8 and a file extension of 3), although a work-around was developed when Microsoft implemented VFAT, that would allow file names of up to 255 characters. Finally, the large cluster size in many versions of FAT meant that a lot of space was being wasted on padding small files to the cluster size.

Naming of FAT versions

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)

Patent information

moved from the article — I don't feel like inocorporating this right now.

[[Note added 18 April 2004:--

Most of this patent stuff is non-neutral, incorrect, and badly sourced (slashdot?). It should probably be removed as a larger portion of the text talks about some opensource view on patents which really has nothing to do with FAT[] : 67.168.183.122

The patent datings quoted above are unfortunately not the correct/relevant ones for prior art purposes, for three of the four MS patents.

USP 5579517, although filed on Apr 24 1995, was based on a "continuation of U.S. patent application Ser. No. 08/041,497, filed Apr. 1, 1993, now abandoned." Thus, its effective filing date was April 1, 1993.

The timeframes of citable prior art for this patent are:

(1) for printed publications or technology in public use in USA:-- -- more than 12 months before the effective filing date (i.e. <=March 31, 1992), or -- before the MS technology was invented (if that occurred less than 12 months before the effective filing date), or

(2) for prior inventions invented in the USA, but not disclosed in printed publication or put in public use before the dates already mentioned:-- -- before the MS technology was invented (whenever that occurred).

USP 5758352 has the same effective filing date as 5579517, i.e. April 1 1993, and the timeframes of citable prior art are the same, too.

USP 6286013 was based on an application which was a "continuation of U.S. patent application Ser. No. 08/356,010, filed Dec. 13, 1994, now abandoned, which was a continuation-in-part of U.S. patent application Ser. No. 08/041,497, filed Apr. 1, 1993, now abandoned."

That means the claims here might have either one of two effective filing dates, either April 1 1993 (for claims that entirely reflect the content of the application filed on that date, shown here by the published content of 5579517), or else Dec 13, 1994, (for claims that are not completely referable to the content of the 1993 application/5579517, but depend on content that was first added to the 1994 application).

In each case, the time-frames of citable prior art are set by the applicable filing date in the same way as noted above.

(One of the keys to this complex scheme mandated by law is that a 'continuation' application copies the content of its 'parent', so all of its content normally benefits from the parent filing date, while a 'continuation-in-part' application partly shares content but partly adds new content, compared with its 'parent', and the effective filing dates are allocated accordingly. For the other complications of defining the timeframes, see 35 USC 102, specially parts (a), (b), (e), and (g).)

End of note added 18 April 2004.]]

Microsoft was recently been awarded the patents for FAT. More information is available here: [1] I have added as much information as possible on it to the article. - DNewhall

fat and hard disk partitions

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)

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)

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)

FAT12 vs. FAT16

Just yesterday, I bought a consumer mp3 player that does not support FAT16, but only supports FAT12 with long file names. I think it interesting that FAT12 is still being used today; MMC cards are formatted, by default, with the FAT12 filesystem (according to one online discussion) because many older digital cameras and what not only support FAT12. I'd like to add this information to this article, but am not sure how to do so. Samboy 03:49, 7 Dec 2004 (UTC)

it'd be nice to add something to the article but i'd like sources first. fat12/fat16/fat32 and long filename support are totally seperate issues, floppies also still use fat12 yet there is no problem with using long filenames on them.

By default, Windows 2000 and Windows XP will change any removable media with a formatted capacity less than 32 megabytes to FAT12 when the media is reformatted. If not reformatted, the original FAT type is left alone. I have not found a way to force Windows 2000 or XP to use FAT16 on sub-32meg media. (All 32meg memory cards have a formatted capacity less than 32meg and get converted to FAT12 when reformatted.)

I tried but could not convince several very talented programmers to write a utility for forcibly formatting sub-32 meg media to FAT16 on Windows 2000 and XP.

The other 'gotcha' with 2000 and XP is the default for media with a formatted capacity of at least 64meg is FAT32, but that can be overcome by manually selecting FAT in the format utility. That makes it FAT16. Between 32 and just under 64 meg, 2000 and XP automatically format as FAT16.

I ran headlong into this with an MP3 player that used MMC media up to 64meg. I used Windows XP to reformat a 32meg MMC and until I was able to connect my MP3 player to a PC running Windows Millennium and reformat the card to FAT16, the MP3 player could not read it. The player was the KB Gear JamP3, which in Me and later is natively supported as two USB Mass Storage drives. (Built in 16 meg and the MMC slot.) Until Windows Me's USB Mass Storage drivers were ported to 98SE, this player required MusicMatch Jukebox to work on Windows versions older than Me. The MMJB software's driver expected to see only FAT16 on the MMC media so it couldn't change it back from FAT12.

i belive there is a windows port of mkdosfs listed on here, i belive that will format with basically any combination of options you want (including some that windows doesn't like so watch out) Plugwash 12:48, 6 March 2007 (UTC)

differences to the "Microsoft Extensible Firmware Initiative"

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)

EOF should be EOC: "end of clusterchain". This is the terminology the Microsoft Extensible Firmware Initiative specification uses. --Jkew 17:55, 18 October 2005 (UTC)

mebibytes

"which limited the maximum space of the filesystem to approximately 32MB of space (however this is far more than a typical 360KB floppy could hold at t"

Are these megabytes and kilobytes or mebibytes and kibibytes? - Omegatron 02:44, Jan 22, 2005 (UTC)

Any way "approximately 32MB" is to some degree "approximately 32MiB", but in this case it sould "slightly less than 32MiB". And the 360MB floppy has 360MiB of (physicaly formatted, logicaly unformatted) storage capacity.

All those megabytes and mebibytes... why so few use it ? --DariuszT 05:22, 8 May 2005 (UTC)

MB, as any long-time computer geek knows, is MegaByte. In an attempt to reduce confusion, which in the opinions of many long-time computer geeks has done anything but, some group cooked up terms like MebiBytes and KibiBytes to mean MegaBINARY Bytes and KiloBINARY Bytes. Their reasoning is that the hard drive industry has "confused" the issue by always listing their capacities in DECIMAL Million Bytes. Then there's the singular example of how the capacity of a 1.44MB floppy disk is calculated different than how a standard MegaByte is.

Confused? Me? Not al all! Instead of trying to get the hard drive industry to use the binary values for MegaBytes and GigaBytes etc, the MiB people exapect everyone to adopt a new "language" of words to refer to exactly the same thing. A MegaByte is still a MegaByte, coming up with a list of words that sound like they're from the Teletubby dictionary doesn't alter that!

1963 origins

For the time being, I've commented out the bit in the history section about FAT being invented in 1963. Unless someone can confirm this, it should be removed entirely. I've also nominated the article Bill Fikes for deletion, and suggest that the matter be debated at Wikipedia:Votes for deletion/Bill Fikes.-gadfium 02:52, 18 May 2005 (UTC)

UMSDOS

Need to check that this is "still in the linux kernel" -- I think if it has not already been removed then it is in the process of removal.

FAT-X or X-Box's FAT

Can someone please add information to the article about the X-Box variation of the FAT filesystem?

Although there are no official documents, as far as I know, there are a lot of reverse enginering and for article enrichment that information should be there.

--Claunia 05:25, 16 Aug 2005 (GMT)

There is some information at http://www.xbox-linux.org/wiki/Differences_between_Xbox_FATX_and_MS-DOS_FAT --Hhielscher 17:12, 3 September 2005 (UTC)

infoboxes

This article currently has 3 infoboxes which give a lot of duplication and make it hard to compare the figures given for the 3 versions of fat. imo we should subst them and then merge them into a single table what do others think. Plugwash 03:14, 30 August 2005 (UTC)

I preferred the single table, as in this version.-gadfium 08:55, 30 August 2005 (UTC)

Well, should better if any of you know how to joind the three infoboxes in just one without converting to simple table. —Claunia 13:42, 31 August 2005 (UTC)

Why do we even have any of these boxes at all? Comparison of filesystems already covers this territory and covers it better. Uncle G 17:57:54, 2005-08-31 (UTC)

Because the idea is not to compare different filesystems but to have easy and clear access to a list of filesystem limits and features. Comparison is a side effect, and Comparison of filesystems lacks some of the information that can be considered VERY important (like the partition types) and makes you have to explore through 59 notes to see why or how something is implemented.

As an example, you can make a comparison of quimical elements, but, will that make the infobox they have useless? No, because the infoboxes wants to provide fast, easy and clear access to additional information about the article, and not compare it with others that are similar.

—Claunia 20:59, 31 August 2005 (UTC)

The number of notes on comparison of filesystems is irrelevant (except to show one of the ways in which it covers this territory better). If comparison of filesystems is lacking partition type information, the correct thing to do is to add another column containing it, not duplicate the comparison tables piecemeal in a second parallel set of tables and articles. Why was augmenting what we already had not done here? Uncle G 08:45:42, 2005-09-01 (UTC)

People come to this page to read about the FAT filesystem, why should they have to refer to another page to find out basic information? The three infoboxes here aren't intended for people to make comparisons between FAT12/16 & 32. They were just created because the infobox doesn't easily allow for having all three in the one infobox. Which is probably my fault since I started the infobox. If someone else doesn't get to it first, I'll eventually get around to tidying up the infobox and this page so there is only one infobox here. AlistairMcMillan 13:56, 1 September 2005 (UTC)

Fragmentation

"It has a serious drawback in that when files are deleted and new files written to the media, the files can become scattered over the entire media making reading and writing a slow process. De-fragmentation is one solution to this, but is often a lengthy process in itself and has to be repeated regularly to keep the FAT file system clean."

Well, this just happen with EVERY and EVERY filesystem everywhere, and is just a matter of the implementator on how to prevent this as possible. It's not a FAT only problem and I think it should be removed and put instead in Filesystem article. Just it is famous because Microsoft implementations of FAT just take no care on fragmentation.

—Claunia 21:20, 8 September 2005 (UTC)

maybe its an issue with how fats designers implemented fat rather than an issue with the structure of the filesystem itself but that would still make it an issue relavent to an article on fat. Do you have a source for your claim that its to do with how ms implemented fat rather than the design of fat itself? Plugwash 21:42, 8 September 2005 (UTC)

There is no document about it comparing fragmentation between filesystem (there is only one between HPFS and FAT under OS/2), and there is no good way to test.

Just filesystems all suffer fragmentation from design, however some guides you in the specification on how to implement it without much fragmentation, but is their nature. You delete and create files that are not equal in size, soon or later it will fragment (except filesystems without support for file fragments like UnixWare Boot File System and ISO 9660-prelevel-3)

Just to be fair, or that paragraph is moved to Filesystem or copied to every and each filesystem article in Wikipedia.

—Claunia 03:53, 9 September 2005 (UTC)

Infobox comments

moved from user talk:plugwash

Thanks for mixing the infoboxes.

Just, DR-DOS added support for FAT32 in version 8.0. I have no access nor to binaries nor to documentation of this version, so I don't know if they still support volume encryption, but I think it doesnt. If you get access to that version, check it. — Claunia 21:05, 8 September 2005 (UTC)

P.S.: Corrected the FAT16 filesize limit, and just, I can assure you that Stacker, Doublespace and Drivespace dont support FAT32 (they don't work just as a big PkZIP xD lol) — Claunia 21:09, 8 September 2005 (UTC)

I knew drivespace didn't support it but i didn't know if the owners of DR-DOS updated stacker or not when they added fat32 support to DR-DOS. the fat32 infobox looked distinctly like it was written by someone who wasn't too aware that dr-dos even supported fat32. Plugwash 21:16, 8 September 2005 (UTC)

Just, DR-DOS has no rights over the Stacker source, and the Stacker company died long ago. So, if they support compressing FAT32 is surely not with Stacker (if I'm not wrong about the license they have over Stacker).

However I've just sent them an email asking about, and the infobox was wrote taking care about new DR-DOS 8 features, and as they do not explicitly name they added support for the (both third party) compression and encryption engines DR-DOS to be FAT32 compatible, it is logical to suppose not, and lot better than saying something not real or checked enough.

—Claunia 03:53, 9 September 2005 (UTC)

They answered, exactly, "We do not support encryption nor compression in our FAT32 drivers.", so, discussion over. — Claunia 05:17, 10 September 2005 (UTC)

FAT 12 in 2000 and XP

What I ran into with FAT12 is that by default, Windows 2000 and Windows XP will format storage media that isn't a hard drive, smaller than 32MB (don't get me started on the MiB thing ;-), as FAT 12. That includes the majority of solid state memory cards labled "32MB" because their formatted capacity is less than 32 megabytes. The user is only presented with the "FAT" option in the Windows GUI.

How I discovered this (though I'm sure it was known to many others at the time ;-) was when I wanted to save time deleting songs from a 32MB MMC in my MP3 player by formatting the card instead of selecting and deleting all the songs. The player could no longer read the card! I then tried forcing it to FAT16 from a command line and the command reported that it was formatting FAT12 in spite of my command switch to use FAT16. I had to hunt up a system running Windows Me to plug the player into to reformat the card to FAT16, whence it again worked in the player. (The player could tell there were files on the card in FAT12 but could not play them.)

Is there a way to forcibly format a sub-32MB piece of storage media as FAT16 in Windows 2000 and XP?

There's another FAT "gotcha" in Windows XP where the default for storage media over a certain size is FAT32, but it's not a problem like the sub-32MB FAT12 issue because the user can just select FAT. (Does Windows 2000 do this too?)

Does anyone know why Microsoft "resurrected" FAT12 for non-floppy storage media with Windows 2000 and XP? It is a nasty problem for devices that use smaller media, can use only FAT16 and do not have the built in capability to format their own media, or can, but only if the card is totally blank or already FAT16.

Really the specification say that FAT12 MUST be used for anything less or equal to 32MB, and FAT32 MUST NOT be used for anything less than 512Mb, but you know, everyone makes what they want in every and every single implementation. Did you tried FORMAT x: /FS:FAT16? It should force it to be FAT16 even is less than 32Mb, if I'm not wrong. —Claunia 12:14, 25 September 2005 (UTC)

Are you sure it was just 2K and XP? Plugwash 15:21, 25 September 2005 (UTC)

"the specification say that FAT12 MUST be used for anything less or equal to 32MB, and FAT32 MUST NOT be used for anything less than 512Mb" Strictly speaking the FAT32 specification says neither of these things. The relevant specified limits here are: "there is no such thing as a FAT16 volume that has less than 4085 clusters"; "there is no such thing as a FAT32 volume that has less than 65525 clusters". At 1 sector per cluster this gives minimum data region sizes for FAT16 and FAT32 of ~2M and ~32M -- well below the limits stated above.

In its discursive voice (and a big problem with the FAT32 spec is that it flipflops between authoritative and chatty) it gives guidelines and descriptions of what Microsoft operating systems do (or at least did do at the time the spec was published): "Microsoft operating systems only do FAT12 on floppy disks"; "if your media is larger than 4MB, do not bother with FAT12"; "For Windows [...] any FAT volume smaller than 512MB is FAT16, and any FAT volume of 512MB or greater is FAT32". It's usually worth following these guidelines, but being aware of which ones are legal to step outside. --Jkew 18:41, 23 January 2006 (UTC)

"The player could tell there were files on the card in FAT12 but could not play them." Sounds like it assumed FAT16 rather than checking (per the spec, the only way to determine the FAT type is from the cluster count); it'd be able to understand the BPB and the root directory, but not the FAT. --Jkew 18:41, 23 January 2006 (UTC)

Drivespace 3

I think, it was removed in Me or 98 S.E., can anyone check? Claunia 14:14, 9 October 2005 (UTC)

It is present in 98 SE for sure. --156.17.36.219 17:03, 3 January 2006 (UTC)

I forgot to update that sentence, it is present in both, however not compatible with FAT32. —Claunia 13:40, 4 January 2006 (UTC)

About FAT support for ADS

As seen on Plugwash's talking and in it comment in the article, we have no proof that FAT supported ANY kind of ADS inside NT.

We all know that it supported EAs under OS/2 in the "EA DATA.SF " file in root, and I have checked that Windows 2000's Services for Macintosh indicates that Macintosh Finder Info and Macintosh Resource Fork get lost when moving to a FAT32 drive.

However I'll investigate further in this issue as soon as possible, on if older SFMs support ADS on FAT drives and if NT can copy EAs to/from FAT drives.

— Claunia 16:59, 26 October 2005 (UTC)

Sorry the file is named "EA DATA. SF" not "EA DATA.SF ", and

----copyrighted data----

DIR_Name[0] may not equal 0x20. There is an implied ‘.’ character between the main part of the name and the extension part of the name that is not present in DIR_Name. Lower case characters are not allowed in DIR_Name (what these characters are is country specific).

The following characters are not legal in any bytes of DIR_Name:

• Values less than 0x20 except for the special case of 0x05 in DIR_Name[0] described above.

• 0x22, 0x2A, 0x2B, 0x2C, 0x2E, 0x2F, 0x3A, 0x3B, 0x3C, 0x3D, 0x3E, 0x3F, 0x5B, 0x5C, 0x5D, and 0x7C.

----end of copyrighted data---

From Microsoft FAT specification.

As you see, it says "less than" but not "less or equal" than "0x20", so " " is a valid character, although no DOS API supported it, and OS/2 and Windows NT/9x think that when you use the space character you want to use a long filename, "EA DATA. SF" is a fully valid FAT 8.2 name.

It also specifies that a filename must not start with a space, but you can put "A FILE. EX", just any space before other character and after character 9 (1 of extension) is ignores (as any space after any other character in the extension).

— Claunia 14:34, 27 October 2005 (UTC)

P.S.: From Cygwin mailing list I saw people saying that NT uses EAs to store their Security Descriptor (of course in HPFS386 ACL format) inside FAT drives, but should check, as I remember that the security section of file properties is missing when using FAT drives in NT.

— Claunia 14:36, 27 October 2005 (UTC)

FAT32 "crippling"

User Adam Mirowski recently added this sentence to the article, with the edit comment "(added a possible justification for fat32 "crippling". The whole paragraph is not quite NPOV)"

On the other side, keeping full support for a legacy lowest common denominator filesystem can cripple the manufacturer as well: for exemple recent Windows security updates want to attach tracking information to files downloaded from the Internet, in the form of Alternate Data Streams, and this is not possible on FAT32.

Here's why I removed it: it does not address the question of why Microsoft prevented users from creating FAT32 partitions larger than 32 GB, when the system supports much larger partitions. This certainly gives the impression of an artificial restriction. I agree that the unattributed statement that Microsoft is "often accused of deliberately crippling FAT32 support" is a problem, and have replaced it with a sourced opinion from Peter Norton.

The sentence would be relevant if it were widely held that NTFS was unneeded and that FAT32 could have sufficed had Microsoft not "crippled" it. That's not the issue, though. The question is not whether NTFS has real advantages over FAT32. The question is why did Microsoft apparently put in an artificial limitation that makes FAT32 less useful than it could be.

Certainly, if someone has a verifiable source that says there is a good reason for restricting FAT32 to 32 GB, that should be added to the paragraph as well. Dpbsmith (talk) 16:37, 23 February 2006 (UTC)

It does not take a rocket scientist to figure out that MS are trying to phase out FAT in favor of NTFS on new installations. This is even said in the next sentence of the KB article. Today's hard disks are greater than 32 Gigs in general; in another KB article, MS encourage OEMs to format hard disks as a single partition, which goes in the same direction. I do not quite understand the thought processes of people complaining about this. Bickering about FAT inadequacies and about MS wanting to drop it is like this old Woody Allen joke:

"Boy! The food at this place is really terrible!

- Yeah, I know. And such small portions!"

One could as well complain about Windows not doing default write caching on FAT32 disks connected through USB (which divides performance by three, experimentally), and then about losing data if cable is brutally disconnected. It is not MS's job to continuously improve horse carriages. Adam Mirowski 02:07, 24 February 2006 (UTC)

I think the real issue is that there is no good universal file system. Third party drivers for ext2 do exist for windows but have to be installed seperately (a major inconviniance if carrying arround data) and apparently suffer from strange bugs (the kind that are hard to reproduce but annoying as hell). NTFS isn't properly supported on anything other than the windows NT line. So other than fat what is there that can be used on external drives/removable media that you wan't to be portable between operating systems? Plugwash 02:24, 24 February 2006 (UTC)

Edit: NTFS support has got somewhat better on other operating systems recently but NTFS-3G must still be installed seperately (yes NTFS-3G does work on OSX at least according to the results of a quick google search). Plugwash 12:53, 6 March 2007 (UTC)

"for exemple recent Windows security updates want to attach tracking information to files downloaded from the Internet, in the form of Alternate Data Streams, and this is not possible on FAT32." <-- given how much hell i've seen people going through trying to clean up malware hiding in alternate data streams i remain to be convinced that such features are a positive for security. Plugwash 12:54, 6 March 2007 (UTC)

dos plus

DOS Plus on the BBC Master 512 did not use conventional boot sectors at all. Data disks omitted the boot sector and began with a single copy of the FAT (the first byte of the FAT was used to determine disk capacity) while boot disks began with a miniature ADFS filesystem containing the boot loader, followed by a single FAT.

Anyone know if it could also read/write standard PC disks? Plugwash 21:26, 25 February 2006 (UTC)

DOS+ for PC and compatibles supported both CP/M and FAT filesystems. Later when it became DR-DOS stopped supporting CP/M filesystems. —Claunia 13:01, 27 February 2006 (UTC)

There's a message in it saying "login_ibm: FAT read failed" which suggests that it does have a concept of an "IBM" format as well as its native formats. HungryHorace 21:38, 8 April 2006 (UTC)

Maximum FAT32 format in WinXP

Hey all. I dont have much experience in Win2k but I have, many times, formatted a 120GB drive with FAT32 in WinXP. It needs to be done from the Microsoft Management Console as far as I've seen, but it is possible.

i thought space was illegal

though some badly behaved tools managed to introduce it, anyone like to clarify? Plugwash 14:39, 12 June 2006 (UTC)

space? what "space"? Tempel 14:48, 12 June 2006 (UTC)

Sorry i should have been a bit clearer, i was reffering to 8.3 filenames. Plugwash 23:53, 8 November 2006 (UTC)

So your point is the the article says that a blank in a 8.3 file name is allowed while it shouldn't? -- Tempel 19:05, 12 November 2006 (UTC)

Whether blanks are allowed in 8.3 filenames or not depends upon the utility in question. The spec may not disallow it, but DOS/Windows may not be able to support it. Specifically, there's no reason not to be able to use it in an FCB (file control block), but there's no way to specify such a file on a command line (without using a wildcard) without using the quoting system introduced much later as part of LFN support. The effective result is that blanks are not allowed in 8.3 filenames. --Scott McNay 22:32, 12 November 2006 (UTC)

FAT32 infos added - cleanup needed

The FAT32 boot sector information was completely missing, as many have pointed out before but no one fixed.

So, since I'm currently writing software dealing with these structures, I've added the information as much as I was concerned with it. There's still some things missing, such as what the File System Information Sector is about, and what some other fields contain (Flags, Version, etc.). Yet, at least it should be easier to add such information now that the table has been separated into parts for FAT12/16 and FAT32.

Also, this discussion page is way too big. I've removed some parts that appear to be handled now by my changes or are old Q&As that do not need to be here any more.

Tempel 14:52, 12 June 2006 (UTC)

Attribute bit 0x40 reference

Are there any sources giving the definition of attribute bit 6 (0x40) as "device"? I haven't been able to find anything online; the Microsoft FAT32 spec simply says "reserved". (It certainly seems to have some meaning to Windows; editing a directory entry to set bit 0x40 leads to an "access denied" file in WinXP.) --Jkew 22:16, 27 July 2006 (UTC)

I seem to recall that this is discussed in the specs for block device drivers. --Scott McNay 22:35, 12 November 2006 (UTC)

FAT32 swap file limit??

The article says:

The maximum possible size for a file on a FAT32 volume is 4 GiB minus 1 B (232-1 bytes). For most users, this has become the most nagging limit of FAT32 as of 2005, since video capture and editing applications can easily exceed this limit, as can the system swap file.

I fail to fully understand this complaint, since individual swap files are limited to 4GB anyway, even on NTFS.

I think this entire paragraph should be removed, since:

"As of 2005", low-end name brand computers were lucky to get drives as big as 40GB.
Windows 98, 98SE, ME, and 2000 are no longer available for sale; XP is now the only one readily available (Vista is now available for beta-testing), and has been the only widely-available OS for about 5 years, and most XP systems have come formatted with NTFS. FAT32 has become Yet Another Legacy File System.
250GB drives are now readily available for under US$100.

I have rewritten the paragraph to indicate that only a decreasing portion of the population is restricted by the FAT32 limits, which is, of course, true for any product (namely, consumer Windows) which is no longer on the market. --Scott McNay 01:30, 30 July 2006 (UTC)

i agree with some of your comments but not others. Afaict fat32 is the only filesystem that enjoys decent support on all major operating systems. The filesize limit is an issue for anyone who runs dual boot systems and wants thier data partitions to work well cross OS and for anyone who uses USB hard drives for portable storage and doesn't stick to windows. Plugwash 01:50, 30 July 2006 (UTC)

"bad blocks" -- list or not?

"Bad blocks: linked list" is wrong, surely -- there's no list of bad clusters, just a bad cluster mark in the FAT for each one. --Jkew 19:23, 1 September 2006 (UTC)

As the FAT is a linked list, and that is the structure that marks bad clusters, it is correct.

If saying a bitmap (alone, it seems it is that), it should be a separate bitmapped structure, but it isn't.

—Claunia 20:02, 1 September 2006 (UTC)

This got me thinking - See Hierarchical_File_System. There the structure for bad blocks is said to be a B*-Tree, while here (for FAT) it's said to be a linked list.

I find both descriptions misleading. In particular, for HFS, the bad blocks, while being somehow ending up in a B-Tree, is not specific enough (I hope you'd agree that saying that the structure for bad blocks is a sequence of bytes is eventually correct as well, but not specific enough). In fact, the way to mark bad blocks in HFS+ is by making them property of a specific "bad blocks file" (how is it done in HFS Standard, I do not remember?). And I think that's what should be the description in the HFS and HFS+ pages, instead of the current unspecific "b-tree" statement.

On the same level, bad blocks on a FAT FS are marked as individual clusters, inside the allocation table (versus being marked as a specific file using a linked list).

Only that way the distinctiveness of the different ways to mark bad blocks on these file systems becomes clear.

Agreed? -- Tempel 08:16, 3 September 2006 (UTC)

I agree with Jkew. Files are a linked list within the file allocation table, but bad clusters and free clusters are merely marked with special reserved free (0) and bad (-8??) codes. Maybe it's different in FAT32, but that's how it is in FAT12 and FAT16. --Scott McNay 22:43, 12 November 2006 (UTC)

It's the same for FAT28, er, I mean FAT32: files are linked lists of clusters, but bad clusters are marked individually and not linked. In fact, almost everything is the same in FAT32, except 1) the root directory is in cluster space, therefore extendable, 2) an new information record contains the number of free clusters and the next cluster to allocate (FAT12/16 keep in the driver's RAM and not on disk). 3) The BPB contains a few extra fields, the most significant is optional FAT mirroring (between copies of the FAT) and bits to indicate which FAT copy is active. — EncMstr 00:39, 13 November 2006 (UTC)

BTW note that you have to use third party software if you wan't to disable the fat mirroring, if you only use MS tools then your forced to have it. Plugwash 11:26, 13 November 2006 (UTC)

32 GB limit

The article says "The FAT32 formatting support in Windows 2000 and XP is limited to drives of 32 gigabytes", but surely it should be volumes of 32 GB, not drives? AnonMoos 01:26, 4 October 2006 (UTC)

agreed. I've changed the article --Tempel 07:31, 4 October 2006 (UTC)

Root directory entries limit

do you have a cite for that fact that the limit can be higher than 512 and do you know if there is a higher hard limit? Plugwash 17:53, 14 October 2006 (UTC)

Provided cite for 512 limit and reverted paragraph to previous version. If someone has a cite proving that limit can excess 512, then please cite it and restore Tempel's version. AlistairMcMillan 18:16, 14 October 2006 (UTC)

Well, the citation is bad because it is a support document for users, not a specification for programmers.

See the MBR's spec: It does not specify a fixed limit explicitly, but instead the number of the entries is specified as a variable value in the MBR. That means, that any properly written software should be able to handle larger root dirs just as well - unless someone can actually quote a spec from Microsoft saying that the max allowed value in this field is 512. I can not find such. The only reasonable hard limit would be 32767 entries, which is the limit for a signed 16 value as provided by the 2-byte field at offset 0x11 in the MBR.

Actually, see the MS article ref'd from our article, which is a specification for the FAT format: standhttp://support.microsoft.com/kb/140418/ -- it says: "Root Entries: This is the total number of file name entries that can be stored in the root directory of the volume. On a typical hard drive, the value of this field is 512" - it says nothing that it can't be higher than 512, though. Which tells me as a programmer that it may' be higher, of course!

So, see? The limit of 512 is rather arbitrary, as I wrote this morning. Convinced? --Tempel 19:42, 14 October 2006 (UTC)

Nope. The document I linked may be aimed at users but I don't think it is wrong when it says "All hard disk drives use 32 sectors of 512 bytes each to store the root directory. This limits the root directory on a hard disk drive to 16K..." and "Each directory entry uses 32 bytes..." 16K/32 = 512.

If you have an actual source that says otherwise, and by that I don't mean "if you take source A and source B, munge them together, you get conclusion C" I mean a source that explicitly says "the root directory of the X implementation of the FAT16 filesystem had more than 512 entries". Do you have anything that says that?

You know, given our policies of Wikipedia:No original research and Wikipedia:Verifiability AlistairMcMillan 20:11, 14 October 2006 (UTC)

Using the "mkdosfs -r 1000 -C disk0 256" command on linux i just created a diskette image with 1000 entries in root directory, copied it to Windows XP, mounted using the filedisk utility, and then could create exactly 1000 files in the root directory. That is original research. But the article could just say that "Third party formatting tools like mkdosfs allow to set the root directory to any size" given that the man page for mkdosfs (a "primary source") says so. I don't know the Microsoft doc Alistair referenced insists on 512 entries and why format.exe does not allow to specify the root directory size. Maybe this is related to compatibility with older MS OS-es and maybe to avoid having the user puzzled about too many choices. Adam Mirowski 19:55, 15 October 2006 (UTC)

Update: Let's not rejoice too soon, fans of "FAT is totally flexible" statement. XP does not properly handle my 1000-root entries disk at all. Files disappear after unmount, chkdsk does not help, strangerly named files appear in the FOUND.000 directory after chkdsk as if one of the files was interpreted as a directory, etc. Maybe mkdosfs messed-up things, or maybe Windows indeed does not support non-standard configs. Adam Mirowski 20:59, 15 October 2006 (UTC)

I looked long and hard for a reference because I was sure I reformatted several FAT volumes with a parameter specifying a larger-than-normal number of root directories. Alas, the MSDOS format command has no such parameter, nor does Central Point's PC Tools PCFORMAT. Did I alter format.com? Maybe, but I don't remember. The traditional handling was to avoid putting files in the root directory. I recall some extremists who created a subdirectory named ROOT where they put everything.

The root entries parameter is in the BIOS parameter block (BPB) in the volume boot sector (VBR)—not the MBR. Each volume on an MBR-partitioned drive could have a different cluster size, and different root directory size. The BPB is documented here and clearly shows an independent parameter. I feel there are ways to affect the value, but I don't know of them—today. — EncMstr 21:45, 15 October 2006 (UTC)

EncMStr - you wrote " I feel there are ways to affect the value, but I don't know of them". For a programmer such as me this is a nonsense remark: I write software that generates volume structures on disks and as such I can create the way to set the root dir size to any value I want. And I've done that myself in times. That's how I came to claim that it's possible in the first place. Just because there is not tool to alter the value available to most people, it's not good enough to say it's not possible (but I know you agree with this - I rather respond to the original criticism of my statement). -- Tempel 11:35, 20 November 2006 (UTC)

I tinkered with the VDISK.SYS source code years ago. Much of the confusion over what the various FAT-related technologies support is due to the fact that you have at least five different variables at work:

the limit as defined by the field sizes. Some field sizes have changed or even been replaced by different FAT versions
the limit as modified by the data type (signed vs unsigned fields); this sometime changes for third-party variants.
the limit as provided by the support tools (such as the FORMAT utility); this is known to change with different DOS and Windows versions.
the limit as provided by the device driver itself.
the limits of various DOS/Windows functions.

In some cases, you also have multiple fields describing the size of the same data structure, sometimes differing by orders of magnitude. For example, both the MBR and the volume boot record contain fields specifying the size of a partition.

I think you'll find that, out of necessity, the block device drivers in Windows XP, 2003, and Vista will support virtually any configuration physically supported by the data structures.

Many years ago, before FAT32 and GPT and maybe before LFNs, I sat down to figure out the hard limits on each structure, and the sources of them; I finally gave up on it, since there were so many variables. I'd probably find it much easier now, by using a spreadsheet to propagate and recalculate the limits at each step.

I'd recommend modifying the infobox to note that the limits listed are the standard limits for modern Windows OSes. For example, subdirectories were not supported before DOS 2. --Scott McNay 23:27, 12 November 2006 (UTC)

When I first altered the article to state that there's no one globally fixed limit of root dir entries, I did this in response to a statement that claimed that it was fixed - that statement was plain wrong because, as now others have shown, it's not only possible from the spec but even doable with existing tools. OTOH, there's also the possibility that some software can't properly handle more than 512 root dir entries, but that's more a limitation of the particular software, not something that invalidates my claim that more than 512 are possible.

Here's a proposal:

Old text

The FAT16 format limits the number of entries in the root directory to 512 (entries being file and/or folder names in the old 8.3 format).[2] Use of long file names reduces this further. Even today, this limitation still applies to certain MP3 players that require the use of the FAT16 file system format.

New text

The FAT16 format limits the number of entries in the root directory to a fixed number, defined at time of formatting. This number is usually 512 entries (entries being file and/or folder names in the old 8.3 format), but larger numbers are possible as well, depending on the formatting software. Use of long file names reduces the amount of possible items in the root directory further. Even today, this limitation still applies to certain MP3 players that require the use of the FAT16 file system format. Care should be taken when consdering to format a FAT16 disk with space for more than 512 root dir entries as not every driver can cope properly with this unusual change - it may even lead to permanent data loss.

Agreed? Then I'll change the article accordingly soon.

-- Tempel 11:35, 20 November 2006 (UTC)

Looks good, although I'd suggest not limiting it to MP3 players; use them as an example, instead. Actually, if an MP3 device has that limit, it probably won't work correctly with LESS than 512 entries either, so I'd say "...for other than 512...". --Scott McNay 13:02, 20 November 2006 (UTC)

Here is my proposal. Find a source that says that there are working FAT volumes with more than 512 entries and then edit the article appropriately. Please either try and work within Wikipedia's rules or if you really don't like them, then change them. Don't just ignore them. AlistairMcMillan 13:53, 20 November 2006 (UTC)

Alistair, haven't the comments from others above given you enough reasons that it's possible? How can you insist in asking for a quote of something that needs to explanation? The Spec for the BPB clearly provides a 16 bit value field and does not explicitly limit it to 512. Just because MSDOS has always used 512, because some number must be inserted into this field, does not mean that it can't have other values! Why is it so hard to accept that? Even other commenters here have agreed to this reasoning. And my proposal should clearly explain that: It says that it can have any value, but that some (badly written) software may not be able to expect something else than 512 there. Yet, I've written software myself that can deal with other sizes, and others have as well, as the comments above suggest. -- Tempel 09:03, 21 November 2006 (UTC)

Here's a source: mozillaquest.com/aboutcomputers/FATData1.html. It contains this statement:

FAT16 partitions have a maximum of 1,024 root directory entries (512 entries is normally used with newly formatted partitions).

So, I still think that Tempel's suggested paragraph is good.

I do not know why there is a 1024-entry limit, especially when there is a full two-byte field to record this, but that's probably irrelevant here. Anything other than 512 for non-floppy media is certainly non-standard. Do you want a source for that statement, or will you accept it as safe?

--Scott McNay 05:57, 21 November 2006 (UTC)

Yes, that 1024 limit is as much nonsense as any other. Where do these people get such ideas from?! It's obvious nonsense, unless they'd give an explanation, which they don't! -- Tempel 09:03, 21 November 2006 (UTC)

My problem with this quoting business is that no one guarantees that the quoted articles are right! The only reliable reference in a tech issue like this is its specification. And such a spec I have quoted above. It quite officially describes the BPB contents, comes from Microsoft's tech department (while Alistair's first quote comes from the user support department and is not a spec), and as I have argued before, that spec is not stating a limit. And any programmer should surely agree that from the spec I refer to one can imagine any possible value up to 32767 at least. If other software can't deal with such big limits - well, that's just a bug in their software then. And that's what my proposal even deals with, so what's the problem? -- Tempel 09:03, 21 November 2006 (UTC)

Alistair, what do you want us to prove here, really? You surely can't say that it's not possible to create a FAT16 volume with more than 512 root dir entries, or do you? Because logic tells us that this is possible - it needs no quote. Agreed?

So, all you can ask for is to prove that some software can properly deal with such a volume, by using all available root dir entries, right? But What tells you that this is not possible, either? Where do you see a need to find a quote for this? Why can't simple intelligence tell us that it works if the software is written accordingly to handle it?

I do not have to prove to you by a citation that 4² is 16, right? Instead it follows from the knowledge that the power of two means to multiply the argument by itself. And 4 mult by itself is 16. That's a logical deduction, it needs no individual quote to prove it. So, where's the difference here? I just don't get it.

-- Tempel 09:03, 21 November 2006 (UTC)

What do you want? Should I just copy and paste the entire contents of WP:VERIFY here? "...logical deduction..."??? How about the entire contents of WP:NOR while I'm at it?

"...I do not have to prove to you..." Actually you do. Have you even read WP:VERIFY? "512" is sourced. Unless you can come up with a credible source that proves otherwise, then that beats any "logical deduction" on your part. AlistairMcMillan 10:45, 21 November 2006 (UTC)

There is a cite but its citing a source that is dubious at best (an end user help page written LONG after the format was devised probablly by a totally different person at MS) Plugwash 11:23, 21 November 2006 (UTC)

Great, love your edit. However could you cite a source to back up this statement: "However microsoft tools have always used a maximum of 512 entries with the actual value depending on the media type"? Oh and while you are at it, could you cite a source for this statement: "Some third party tools like mkdosfs allow the user to set this parameter but there are likely to be compatibility issues in use of nonstandard values."? AlistairMcMillan 12:40, 21 November 2006 (UTC)

We do have a spec, in a way: the long-obsolete Media Descriptor at offset 0x15 in the BPB. 0xF8 is the code for a fixed disk (basically anything other than a floppy). Single density media (180K) has 4 sectors, double density media (360K and 720K) has 7, high density media (1.2M and 1.44M) has 14, and hard drives up through at least 40 MB have 32. I would not say "maximum", since each type of media always had a specific number of root directory records. "Maximum" implies that anything goes, up to the limit.

My suggestion would be to simplify to something like "For historical reasons, FAT12 and FAT16 media generally use 512 root directory entries on non-floppy media, and other sizes may be incompatible with some software or devices."

Ref: "The New Peter Norton Programmer's Guide to the IBM PC & PS/2", by Peter Norton and Richard Wilton, Microsort Press, 1985.

Media descriptor values, page 104, figure 5-3. Offset of media descriptor (0x15) and offset and size of field with number of root dir entries (0x11, 1 word), page 111, figure 5-9. Number of entries for various media, page 111, figure 5-10.

--Scott McNay 06:21, 22 November 2006 (UTC)

2 TiB limit

The article states that a FAT32 volume should "support a total of approximately 268,435,438 (< 228) clusters, allowing for drive sizes in the range of 2 terabytes". The same limit is stated in the summary window. Howewer, this site states that with a cluster size of 32 KB, you can reach a size of 8 TiB. I'm no expert of clusters and how they work so i didn't dare to change the article.

I changed it to 8TiB but some time after doing so i noticed that http://www.ridgecrop.demon.co.uk/index.htm?fat32format.htm says "FAT32 itselft should be OK to 2TB, limited by a 32 bit sector count in the boot sector". This needs investigating in more detail. Plugwash 23:39, 8 November 2006 (UTC)

Undoing edits without a citation - not this way!

This is about the recent addition of the "Fragmentation" topic. I read it, understood and agreed with it technically and generally. From someone who has a lot of experience writing software for many file systems (Commodore VC-1541, Apple DOS 3.3, CP/M, DOS FAT, HFS, ISO 9660, Joliet, UDF, and others) for over 20 years I think I have a saying about this.

What happened is, that after someone added a long section, someone else removed it again, referring to WP:VERIFY.

I do not agree with the policy that someone thinks he can again remove such additions without a discussion here, simply by pointing out missing citations. This had happened to an addition of mine before as well, so this is not the first time this happens. And that's why I bring it up now.

Alistair - if you do not agree with technical details others have added, then please first discuss them here before you remove them. Just because no citication can be found does not mean it's wrong. Citations are only needed when it's not common knowledge or when it's not deductible. The techinical details in these kind of articles here, though, need to citations when they can be deducted from logic, common sense or experience.

If you need it verified, then please ask instead of just invalidating the addition by removing it.

What do others think? If you agree, please speak up in order to tell Alistair not to do this again this way. Or tell me if I stepped out of line.

-- Tempel 14:29, 16 November 2006 (UTC)

WP:VERIFY says that the author has the responsibility to source any changes. What I've seen in other articles is that text that other editors agree with is left alone, text that looks plausible but other editors would rather see a source to confirm their feeling is left in with either a cite tag or just a question on the talk page, text which an editor has doubts about is MOVED to the talk page until it can be sourced, and "patent nonsene" simply gets deleted outright. As you can see, WP:AGF is applied.

If an author claims to be or seems to be a subject matter expert, or at least reasonably knowledgeable, and evidence seems to back this up, my tendency is to AGF as long as stuff seems to be consistent. --Scott McNay 02:58, 17 November 2006 (UTC)

...after someone added a long section...

The comment by AlistairMcMillan from here was moved down to a new section called Fragmentation section discussion.

I'm sorry if I appear to have acted hastily in removing Adam's edit, but I do spend a lot of time tidying up other people's edits, searching for sources and adding them when other people can't be bothered (even though the words "Encyclopedic content must be verifiable." are right there between the main edit box and the edit summary box). Sometimes it is just easier to remove the whole thing and hope they'll try again with sources. Sorry for any offence caused. AlistairMcMillan 17:12, 18 November 2006 (UTC)

The comment by Scott McNay from here was moved down to a new section called Fragmentation section discussion.

Now we've reached the point where we actually discuss the contents of the added chapter. That's all I asked for. I also accept Alistair's apology for a -perhaps- too hasty reaction. Thanks. I will take the liberty and split up this section into two - one about my original topic and one about the content discussion, I hope that's OK with you both, Alistair and Scott. -- Tempel 10:33, 20 November 2006 (UTC)

Fragmentation section discussion

This is about the Fragmentation section recently added by "Adam". Some editors have raised concerns about the text.

Adam described his addition as a "discussion" which is not appropriate for an encyclopedia. Unless of course he was just mentioning a discussion which had taken place elsewhere, which without cited sources we have no way of telling.

His addition suggested ways to fix FAT, which is not appropriate for an encyclopaedia. Unless of course he was mentioning things that other people had suggested as fixes, however without cited sources again we have no way of telling.

A quick glance at his Talk page and Contribution list shows that the last time someone asked for sources to back up a contribution to this article, they were met with silence.[2]

Another thing that bugged me about the discussion, is that it isn't clear which version of FAT we are talking about. Are all of them affected in the same way? Is it just some of them? Were any changes made between versions to attempt to lessen the problem?

AlistairMcMillan 17:12, 18 November 2006 (UTC):

Ok, I went and found the edit in question, and pasted it below with my comments.

Fragmentation

Because of its simplicity, the FAT filesystem does not contain mechanisms which prevent newly written files from becoming scattered accross the partition. Scattering implies latency-causing disk head movements during subsequent accesses.

I'd reword this slightly, but otherwise ok.

Such mechanisms could have been the presence of a bitmap indicating used and available clusters, which could then be quickly looked up in order to find free contiguous areas (improved in exFAT). A similar mechanism could be the linkage of all free clusters into one or more lists (as is done in Unix filesystems). Instead, the FAT has to be scanned like an array in order to find free clusters, and nowadays it generally cannot fit in memory.

I'd either delete or rewrite from the viewpoint of other filesystems.

In fact, computing free disk space on FAT is one of the most expensive operations, as it requires reading the entire FAT linearly. A justification Microsoft offered for limiting the maximum size of FAT32 partitions created on Windows was the time required to perform a simple "DIR" operation, which always displays the free disk space as the last line. Displaying this line took longer and longer as the number of clusters increased.

I seem to recall that FAT32 has a free-space field to hold this. I've noticed the slowness in displaying the free space on older FATs, but this is more appropriate elsewhere in the article, not in a fragmentation section.

Another mechanism could have been the division of the disk space into bands where multiples files opened for simultaneous write could be expanded separately.

Delete

Some of the perceived problems with fragmentation resulted from operating system and hardware limitations.

Delete

The single-tasking DOS and the traditionally single-tasking PC hard disk architecture (only 1 outstanding input/output request at a time, no DMA transfers) did not contain mechanisms which could alleviate fragmentation by asynchronously prefetching next data while the application was processing the previous chunks.

Delete

Similarly, write-behind caching was often not enabled by default with Microsoft software (if present) given the problem of data loss in case of a crash, made easier by the lack of hardware protection between applications and the system.

Delete

MS-DOS also did not offer a system call which would allow applications to make sure a particular file has been completely written to disk in the presence of deferred writes. Disk caches on MS-DOS were operating on disk block level and were not aware of higher-level structures of the filesystem. In this situation, cheating with regard to the real progress of a disk operation was most dangerous.

I seem to recall this being added by MS-DOS at some point. In any event, doesn't seem relevant to fragmentation.

Modern operating system have introduced these optimizations to FAT partitions, but optimizations can still produce unwanted artifacts in case of a system crash. A Windows NT system will allocate space to files on FAT in advance, selecting large contiguous areas, but in case of a crash, files which were being appended will appear larger than they were ever written into, with dozens of random kilobytes at the end.

Edit

It should be noted that with the large cluster sizes, 16 or 32K, forced by larger FAT16 partitions, the external fragmentation does not play a great role, and internal fragmentation, ie. disk space waste starts to be a problem instead.

Does the article define internal and external fragmentation?

Would it be more appropriate to have a single sentence or para, and point to a Fragmentation article?

--Scott McNay 05:50, 19 November 2006 (UTC)

Followup: I see that Adam restored his section, and added some cites. The text appears to be the same, so my comments still stand. I don't have a problem with cites, as it all pretty much fits what I know; my concern is, as Alistair mentions, unencyclopedic tone. Even if every sentence were cited as being someone's quote, it still wouldn't fit.

Instead of deleting, some rewriting could be done, comparing the FAT way of doing things with other filesystems. I agree that describing how to fix it is not appropriate here, but the same discussion, written as a comparison (so that people can understand how significant the limitations are) would probably be appropriate. --Scott McNay 06:02, 19 November 2006 (UTC)

I agree with some of both Alistair's and Scott's concerns, not with others. In summary, I'd like to see the fragmentation issue "discussed" in some way to answer the question: Do FAT file systems avoid fragmentation, and how, any why (...not)? This would be a deeper analysis of the introduction in the header of the article where it's stated that FAT vols have a rather poor performance, partly due to quick fragmentation. Would you agree? I ask because I am not sure what Alistair meant: Does he only disapprove of the form or of the content in general?

Provided you all agree that in general such a section is worthy of being in this article, I'll comment on the contents and form now:

I would not delete as much as Scott would, but his questions about some details are valid. Some of the more vague statements rather belong in a "Fragmentation" article than here.

Perhaps we should see that we rewrite the entire section to be much more brief and just state the relevant facts such as:

The inherent structure of a FAT volume requires relatively (compared to other FSs) large amounts of memory and CPU power to avoid fragmentation (examples of better uses such as in HFS and other FSs should be mentioned)
Perhaps we can give an example of the memory consumption for a modern "full" FAT hard disk
I believe that this is generally relevant to FAT16 as well as to FAT32 (to answer one of Scott's questions)
The parts in Adam's article that mention how operating system and their drivers (write-behind cache, multi-threaded FS, a missing file pre-allocation API function, etc.) could better deal with the problem could be mentioned in a much briefer form, if at all (in my opinion, on a modern PC with lots of RAM the whole thing is of much less importance as it used to be a few years ago). After all, this is not even a FAT-specific issue.
The part with "Windows NT system will allocate space to files on FAT in advance," should be kept, as it explains some shortcomings many users might see (that's one reason why one wants to run scandisk after a crash). However, this is not unique to FAT, either, and should perhaps instead mentioned in a Fragmentation article.

Adam, are you still following this? Would you be willing to rewrite the article and move the more general parts (i.e. about OS behavior) to a separate article on fragmentation?

-- Tempel 11:17, 20 November 2006 (UTC)

You said "Do FAT file systems avoid fragmentation, and how, any why (...not)?". From my viewpoint, I'd have to say that I don't think it IS possible to avoid fragmentation, although you can minimize it. And, the FAT system is sufficiently flexible that any method used by another filesystem can probably be adapted to FAT (someone with more experience with other filesystems could probably comment on this more intelligently), since much, most, or all of it is just Al Gore-ithms (ha ha) in the OS anyway (deciding where to put x, and then allocating y amount of space). I gotta get to work; I can write later on the memory consumption (which should be in the article anyway, and might already be, in the FAT section) and so forth. Much of this discussion is OS-specific (implementation-specific). --Scott McNay 13:16, 20 November 2006 (UTC)

Sure but if the specs don't say anything about avoiding fragmentation and none of the major implementations do anything much to avoid it then imo it is reasonable to say that fat as practically implemented is fragmentation prone. Plugwash 13:36, 21 November 2006 (UTC)

Long filenames

This is a good article about a complex subject. But even though it is big, it needs more details about LFNs. It would be good if we could deal with LFN details in the separate article, but right now it is very short on tech details, and it does sort of make sense for them to be here, in the context of FAT details. *** What algorithm does each version of windows use to generate 8.3 names? 98 seems to just use FILSIX~n and count up. XP starts that way, but then takes off and generates much odder forms. Under what situations does each version of Windows just use 8.3, with no LFN? How can the presence or absence of a LFN form be seen by the user? Does each version of Windows treat 8.3 names the same? 98 seems to treat them as UPPERCASE, XP seems to treat them as lowercase, which seems to mess up filestructures when files are moved from XP to 98 via FAT USB flash drive. Is this true? Where is it documented? How to deal with the problem? Archives seem to store only the LFN, not the 8.3? The 8.3 would be regenerated by the receiving FAT when the archive is unpacked? So the 8.3 could change -- is this a problem? 69.87.203.23 00:07, 23 January 2007 (UTC)

Media descriptor

The Boot Sector section has a table within a table (the BPB) that lists Media decriptor values however this seems rather idealistic and incorrect. Please refer to Microsoft's Knowledge Base article on Standard Floppy Disk Formats Supported by MS-DOS. Uzume 08:55, 23 January 2007 (UTC)

FAT24 - does it exist?

I remember to have seen in Norton Disk Editor a FAT24, but I don't see it in this wikipage. Does it exist? —The preceding unsigned comment was added by 82.188.163.3 (talk • contribs) 2007-03-21T11:24:41 (UTC)

Google gives 1,700 matches for FAT24, many of which are company names or dietary numbers (like fat24, carbs37, protein7). Compare that to almost 2 million for FAT16 and over 6 million for FAT32. FAT24 appears to be misused (like here) when applied to filesystems, some thinking it is a big FAT16 (that is, over 32 MiB). FAT24 is not an official standard. Norton might support it just because it could be of use to someone, somewhere writing a custom filesystem. Or using it to view tables of 24 bit values and not a filesystem at all. —EncMstr 15:34, 21 March 2007 (UTC)

Retrieved from "http://en.wikipedia.org../../../f/i/l/Talk%7EFile_Allocation_Table_04fb.html"

Talk:File Allocation Table

From Wikipedia, the free encyclopedia

Contents

FAT+

Error report

Neutrality

Naming of FAT versions

Patent information

fat and hard disk partitions

FAT12 vs. FAT16

differences to the "Microsoft Extensible Firmware Initiative"

mebibytes

1963 origins

UMSDOS

FAT-X or X-Box's FAT

infoboxes

Fragmentation

Infobox comments

FAT 12 in 2000 and XP

Drivespace 3

About FAT support for ADS

FAT32 "crippling"

dos plus

Maximum FAT32 format in WinXP

i thought space was illegal

FAT32 infos added - cleanup needed

Attribute bit 0x40 reference

FAT32 swap file limit??

"bad blocks" -- list or not?

32 GB limit

Root directory entries limit

2 TiB limit

Undoing edits without a citation - not this way!

Fragmentation section discussion

Long filenames

Media descriptor

FAT24 - does it exist?

Views

Navigation

interaction

Search