Talk:File Allocation Table/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

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!

kilobytes and kibibytes aren't exactly the same. kilo is 1,000 (10^3), while kibi is 1,024 (2^10). the 1.44 of floppies is cited as an example because these are mixed. the actual size of a formated floppy is 1,474,560 = 1.44 * 1000 * 1024. the actual size of a floppy should be about 1.47MB or 1.41MiB.

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)

I've changed the introductory paragraph to refer to directory fragmentation, because that was the main issue in FAT filesystems. NTFS has a different and smaller problem with 'directory' fragmentation, so NTFS has a different and smaller problem with fragmentation. If you have a copy of DOS installed, you can see the effect of directory fragmentation by running FASTOPEN with a badly fragmented disk. Fastopen can be run under Windows 3.x, but was not normally, because Windows File Manger was not Fastopen aware. (david) 218.214.18.240 12:20, 10 June 2007 (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)

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:

1. "As of 2005", low-end name brand computers were lucky to get drives as big as 40GB.
2. 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.
3. 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)