Talk:File Allocation Table

This  level-5 vital article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Microsoft Windows: Computing Mid‑importance This article is within the scope of WikiProject Microsoft Windows, a collaborative effort to improve the coverage of Microsoft Windows on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Microsoft WindowsWikipedia:WikiProject Microsoft WindowsTemplate:WikiProject Microsoft WindowsMicrosoft Windows articles Mid This article has been rated as Mid-importance on the project's importance scale. This article is supported by WikiProject Computing.

Text and/or other creative content from this version of File Allocation Table was copied or moved into Design of the FAT file system with this edit on 2014-05-20. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists.

I am somewhat of an expert (PhD) about this topic. I came to this article in search of technical details about FAT16B. I agree that the article is overly long, but it is organized well enough and it contains much useful information.

My problem about the article is in its 'foreground' layer of writing. It is among the most difficult pieces I've had to parse on Wikipedia or elsewhere. One small example: "... originally had a maximum power-of-two value of 64"; this could be stated simply as, "... originally had a maximum value of 64." If the fact that 64 is a power of 2 were important in-context (which it isn't), the author should have started a new sentence to explain that point.

A longer example that I find difficult to parse: "On unpartitioned media the volume's number of hidden sectors is zero and therefore LSN and LBA addresses become the same for as long as a volume's logical sector size is identical to the underlying medium's physical sector size."

And here's an annoyingly long run-on sentence: "While the design of the FAT file system does not cause any organizational overhead in disk structures or reduce the amount of free storage space with increased amounts of fragmentation, as it occurs with external fragmentation, the time required to read and write fragmented files will increase as the operating system will have to follow the cluster chains in the FAT (with parts having to be loaded into memory first in particular on large volumes) and read the corresponding data physically scattered over the whole medium reducing chances for the low-level block device driver to perform multi-sector disk I/O or initiate larger DMA transfers, thereby effectively increasing I/O protocol overhead as well as arm movement and head settle times inside the disk drive."

I don't wish to be overly critical, since the article has much of value to offer. But it strikes me that whoever was the principal author(s) had little training in expository writing. I do not have time to edit the piece myself, but it really needs a good editor.

Neumation scribe (talk) 09:10, 14 April 2013 (UTC)[reply]

Please see WP:SOFIXIT and WP:COLLAB for suggested ways to proceed. Keep in mind that we are all volunteers. —EncMstr (talk) 20:06, 14 April 2013 (UTC)[reply]

@EncMstr: – See WP:I do not have time to edit the piece myself and Category:Good Wikipedia editors. Nothing to be gained by disrespecting someone who took the time to post some good advice, and has to date only edited two talk pages. Wbm1058 (talk) 21:26, 29 June 2014 (UTC)[reply]

@Wbm1058:: I am confused by what your point might be. Did you notice that interaction occurred over 14 months ago? Also, your links go nowhere: is your point that there are no "Good Wikipedia editors"? —EncMstr (talk) 02:48, 30 June 2014 (UTC)[reply]

OK, yes, I did see that this section was over a year old. I came to this talk page because of a notice posted at Wikipedia:Administrators' noticeboard, and indeed the discussion on length and splits is below. Frustrated by that discussion, I backed up to here. I see that Neumation scribe recognized a major issue with this article, and said "I do not have time to edit the piece myself", so telling him to "sofixit" seems kind of rude. He also said it really needs a good editor, so maybe a more appropriate response would be to advertise the need for a good editor to help. I also point out below that this issue remains unresolved, and I think that has a lot to do with this degenerating into the RfC below. Wbm1058 (talk) 14:39, 30 June 2014 (UTC)[reply]

To be honest, I was confused by your comment as well, Wbm1058. It never occurred to me that EncMstr's reply to Neumation scribe could be interpreted as being disrespectful. To the contrary, I found his reply rather diplomatic, even encouraging, given that Neumation scribe's original comment was rather disrespectful (although he tried to sugar-coat it).

I guess it's time to archive some of the threads, which have long been addressed or are outdated and talk about an article still in a very different shape compared to its current form. They just cause confusion. --Matthiaspaul (talk) 00:07, 1 July 2014 (UTC)[reply]

@Matthiaspaul: He's talking to you:

• See Expository writing and Foregrounding, but these just give a brief overview, and I'm not a writing expert either.
• "originally had a maximum power-of-two value of 64"
• "On unpartitioned media the volume's number of hidden sectors is zero and therefore LSN and LBA addresses become the same for as long as a volume's logical sector size is identical to the underlying medium's physical sector size."
• "While the design of the FAT file system does not cause any organizational overhead in disk structures"... (This sentence can still be found, unchanged, in the Design of the FAT file system article)

It's been over two years since I edited this article, and I've only made half a dozen edits, but maybe I'll try to help. Wbm1058 (talk) 21:26, 29 June 2014 (UTC)[reply]

Sure, Wbm1058. I for one would certainly welcome other constructive and capable editors contributing to this article as well.

Of course, I took Neumation's comments under consideration, although they reveal that he isn't an expert on the subject (it doesn't matter at all to me, it's just odd, because he emphasized it so much - and this is also the only reason, why I feel obligated to comment on it).

I didn't address his issues myself, because I found his first two items to be invalid. IMHO, the existing text is perfectly fine, accurate, and easy to understand. While it's always possible to rephrase it, I certainly don't edit the article just for the sake of editing. Those alternatives I can think up would only become longer without improving readability (and at the time of his comment, that is, before the article split, we still had size issues) - and, yes, it's important that it is a power-of-two value, or I wouldn't have mentioned it. Regarding his third item, sure it could be refactored. It just wasn't in my focus so far.

Also, while I do take care that we keep the level of quality already achieved and even strive to further raise it, I don't feel "responsible" to act on each and every good or bad faith comment on a talk page, in particular not when I don't think it would be an improvement. Wikipedia is the encyclopedia anyone can edit, so if someone has good ideas, they don't need me to edit the article themselves or make useful suggestions on the talk page. Over the years I may have become one of the principal authors and editors of the article, and in the software world this might have made me a maintainer, but Wikipedia does not have a concept of one person being "in charge" for an article and I'm certainly not the only editor around who could address issues. So, if you think, you can improve the prose in Neumation's items without sacrifycing the accuracy, please do it.

I love good prose, but so far my primary focus on this article was utmost technical accuracy and completeness, as Wikipedia still has years to come to further improve the prose, even when those with the necessary detailed background knowledge may no longer be around. Also, I have found most technical books/articles with a particular emphasis on "expository writing style" to be rather fluffy, ambiguous, incomplete, sometimes downright faulty and effectively useless in practise, that's why I deliberately set different priorities in my own publications. But this does in no way mean, that we shouldn't improve the prose here for as long as we don't loose the accuracy.

Nevertheless, I wonder, why people, who claim to be better editors, don't just fix, what they think can be improved, instead of putting this burden onto an editor, who's first language isn't English. It should be obvious, that my wealth of expression and active vocabulary is limited compared to native English speakers. --Matthiaspaul (talk) 00:07, 1 July 2014 (UTC)[reply]

Hi Matthiaspaul. Sorry if I took a little sugar off the comments, but Neumation does make valid points. But I don't wish to be overly critical either. Your strength is clearly in getting "utmost technical accuracy and completeness", but at some point the main article may be too complete. Wikipedia:Summary style is used to split sections into new articles, where the main article summarizes the most important facts, while details of less importance are relegated to the sub-articles. Thus, if the sub-articles are included, you still have the desired completeness. The idea is that a reader who just wants a broad overview can read the main article, and only read sub articles if they want to know more of the details. I'm not sure about the best way to split, but right now I'm thinking that splits to FAT12, FAT16 and FAT32 might be a good approach. Of course a summary of each would still be in the main article.

I see that you are also a significant contributor to the German version de:File Allocation Table. How do you feel about the status of that article versus this one? I'll take a look at that to see how it compares when I get a chance. Although I studied Deutsch for 7 years (a long time ago), I will rely on Google translate as my crutch.

Getting this right may take a while, and my time is getting spread thin as I've broadened my scope quite a bit since working on the DOS timeline. I'll try to fit it in my work queue. Regards, Wbm1058 (talk) 23:44, 2 July 2014 (UTC)[reply]

Please see Talk:File_Allocation_Table/Archive_6#RFC_on_length_and_splits and some of the other (prematurely) archived material. Improving this article may be more difficult than you might assume. ~KvnG 13:03, 3 July 2014 (UTC)[reply]

Well, yes, it's somewhat bad form for an involved editor to archive an RfC before someone not involved closes it, but I don't envy anyone trying to draw any conclusions from the discussion (which I haven't studied in depth). However, I question whether splitting based on either historical evolution or comprehensive technical details is the way to go. Your edit totally carved entire sections, without leaving behind any summary. That's the part that takes some good writing skill, writing the summaries. I think that the broad evolution should remain in the main article. Wbm1058 (talk) 17:09, 3 July 2014 (UTC)[reply]

Closing the RfC doesn't look that difficult to me. There doesn't appear to be consensus behind my bold edits and the RfC is now OBE as Matthiaspaul went ahead and implemented his own solution (without first obtaining consensus). The article is improved with respect to where it was a couple months ago so I'm not complaining or reverting. ~KvnG 17:04, 7 July 2014 (UTC)[reply]

I have closed The RfC per continued discussion here and the request at WP:ANRFC. You are correct that I find no consensus; what I do find is a seemingly unresolved, but fundamental, difference of opinion between two editors. I would council that any further differences of opinion between the same parties should be pursued via WP:DRN. Bellerophon _{talk to me} 18:19, 13 July 2014 (UTC)[reply]

The information on the FATX epoch is somewhat confusing. I cannot tell if "in FATX, the epoch is 2000. On the Xbox 360, the epoch is 1980," is meaning to say that FATX itself uses an epoch of 2000 but on the 360 is modified to use an epoch of 1980. I used to reverse engineer and write applications for modifying the contents FATX-formatted devices, and these applications displayed timestamps fine with an epoch year of 1980. Here's a link to one of my very old project's code, showing that the year is given as timestamp year value + 1980 (user images show valid dates as well). Is it acceptable to just remove the part I quoted above since FATX is only used on the Xbox 360, and the epoch does not differ from normal FAT?

Landaire (talk) 23:00, 6 June 2015 (UTC)[reply]

The right hand summary box does not contain size limits for FAT16 This is commonly known as 2GB with 32kB clusters

The value given for "Max. number of files" "65,536 for 32 KB clusters" cannot be correct

According to https://support.microsoft.com/en-us/kb/118335 the "The FAT file system is limited to 65,525 clusters." A usable default format must reserve a number of units for root directory entries etc. The summary box for FAT states a more credible limit "FAT16: 65,460 for 32 KB clusters" — Preceding unsigned comment added by 82.13.252.157 (talk • contribs) 08:38, July 31, 2015 (UTC)

According to https://support.microsoft.com/en-us/topic/default-cluster-size-for-ntfs-fat-and-exfat-9772e6f1-e31a-00d7-e18f-73169155af95 FAT32 volume size is wrong. The tables on that website also have NTFS, FAT16, and exFAT. JarvMonster (talk) 02:27, 17 June 2021 (UTC)[reply]

thereby blowing up dimensions, is probably not meant to be in this article. can someone fix this??? — Preceding unsigned comment added by 69.165.131.74 (talk • contribs) 00:39, June 13, 2015 (UTC)

Hello fellow Wikipedians,

I have just modified 3 external links on File Allocation Table. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20110720115141/http://patersontech.com/Dos/Byte/InsideDos.htm to http://www.patersontech.com/dos/Byte/InsideDos.htm#InsideDos_44
• Added archive https://web.archive.org/web/20130507183540/http://www.microsoft.com:80/en-us/legal/intellectualproperty/IPLicensing/Programs/exFATFileSystem.aspx to http://www.microsoft.com/en-us/legal/intellectualproperty/IPLicensing/Programs/exFATFileSystem.aspx
• Added archive https://web.archive.org/web/20130930190707/http://www.cipa.jp/english/hyoujunka/kikaku/pdf/DC-009-2010_E.pdf to http://www.cipa.jp/english/hyoujunka/kikaku/pdf/DC-009-2010_E.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 13:21, 31 December 2016 (UTC)[reply]

Hello fellow Wikipedians,

I have just modified 2 external links on File Allocation Table. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20120330171510/http://macarlo.com/fat32v074.htm to http://macarlo.com/fat32v074.htm
• Corrected formatting/usage for http://www.microsoft.com/en-us/legal/intellectualproperty/IPLicensing/Programs/exFATFileSystem.aspx

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 01:47, 27 July 2017 (UTC)[reply]

Hello fellow Wikipedians,

I have just modified one external link on File Allocation Table. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20090822044026/http://www.microsoft.com/presspass/press/2003/dec03/12-03ExpandIPPR.mspx to http://www.microsoft.com/presspass/press/2003/dec03/12-03ExpandIPPR.mspx
• Added {{dead link}} tag to ftp://ftp.microsoft.com/misc1/PEROPSYS/MSDOS/KB/Q78/4/07.TXT
• Added {{dead link}} tag to ftp://ftp.microsoft.com/misc1/PEROPSYS/MSDOS/KB/Q68/1/76.TXT

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 16:20, 30 September 2017 (UTC)[reply]

in the section overview: concepts the article contains the line 'each of these variants is still[when?] in use'. The [when] tag does not seem appropriate as that is clarified in the section FAT12. The quickest way to find the information is to search for 2.88. As a side note, even though actual floppies are becoming rare, the use of floppy images for CD booting, virtual machines, network booting, and other uses keeps fat12 in use. For references for current usage look at syslinux's memdisk, vbox (or any other virtual machine), and mkisofs's man page. 71.212.217.88 (talk) —Preceding undated comment added 20:53, 16 October 2017 (UTC)[reply]

quote " Directory entries are 64 bytes in size instead of the normal 32 bytes. " then links back to FAT which says the entries are 8-BIT -not- BYTE

I would like some third party clarification on this, and I am not familar, but I believe the word "bytes" to be in error. It should be "bits" right?

Thank you for your time! --74.142.114.150 (talk) 23:33, 15 December 2018 (UTC)[reply]

That must be definitely bytes. There is one problem with the nomenclature: FAT (File allocation table) can refer to a data structure in the file system that makes contiguous files from files that are scattered at many places on the disk and it can refer also the the file system itself, because the table has an important role in it.

Why not bits? It is simple. All FAT variants have file names in so called 8.3 format. That is file name consisting of 8 characters (= bytes), dot, and another three characters. The dot is not actually stored. The name therefore occupies 11 bytes in the directory entry. If the directory entry would have 32 or 64 bits (what a strange unit for disk structures, bytes are used everywhere else), equivalent to 4 or 8 bytes (1 byte = 8 bits, at least in this case), it could not store even the name of the file. And we have to store starting cluster block address and other information. Okterakt (talk) 11:36, 25 May 2022 (UTC)[reply]

This article says the time resolution of the 'created time' is 10ms. But I found this reference on the net: https://staff.washington.edu/dittrich/misc/fatgen103.pdf which says the resolution is only 100ms. Could the figure 10ms be a mistake, arising from the actual resolution being 'tenths of a second', not 10ms?

Avl (talk) 16:27, 22 January 2019 (UTC)[reply]

I think all the FAT patents have expired in 2011-2018:

• 5367671 in 11/2011
• 5579517 in 4/2015
• 5745902 in 4/2018
• 5758352 in 9/2017
• 6286013 in 1/2017

IANAL, but these can be verified using patent databases and calculators.

2001:14BA:1AFC:72F0:0:0:0:E18 (talk) 01:56, 26 February 2019 (UTC)[reply]

@Klbrain: Your close does not seem like an accurate summation of consensus. I made a precedent- and policy-based argument for merging, and another user concurred. A novice editor objected with a non-policy-based argument, and an IP editor concurred. It does not look like there is consensus to me, so I would advise leaving the discussion open. {{u|Sdkb}} ^talk 21:25, 14 January 2023 (UTC)[reply]

Thanks for the feedback. Novice and IP editors may not phrase their objections in ways that point to policy, but their arguments may nevertheless be consistent with them. My reading of the objections by Okterakt and 134.16.78.202 was that they were consistent with WP:NOTMERGE points 1. and 2.; then, applying WP:SILENCE (noting that the discussion was untouched for 5 months) a close seemed reasonable to me. I wonder where it might be better to improve (which everyone agrees with) rather than (or before) merging? Feel free, though, to propose and actively manage a new discussion; the current policy for silence allowing a merge is 2 weeks (see Wikipedia:WikiProject Merge#Closing Merger proposals to begin merging). Klbrain (talk) 10:11, 15 January 2023 (UTC)[reply]

@Klbrain, I don't think WP:NOTMERGE points 1 and 2 apply at all. An introductory article should contain the same info as its just non-introductory counterpart, just simplified. If the non-introductory counterpart has too much info (exactly the problem here), it needs to be shortened, not used as an overflow dump.

My main concern here was the improper use of the {{Introductory article}} tag, so I've switched the hatnotes to better options. Beyond that, I'm not enough of a CS editor to care to push this further. But I would highly recommend that editors in the future consider it, keeping in mind that all Wikipedia articles, being in a general-purpose encyclopedia, need to be written for a general audience. We have yet another example of a million here of Wikipedia's nonfunctional merge system, and when we finally get around to merge reform perhaps I'll revisit this. {{u|Sdkb}} ^talk 16:37, 15 January 2023 (UTC)[reply]

I absolutely agree with the argument that introductory article tags were not appropriate. Thanks for removing. Klbrain (talk) 15:53, 16 January 2023 (UTC)[reply]

Are flash file systems implemented as FAT or do they appear as FAT with respect to external APIs?

DGerman (talk) 17:16, 6 June 2022 (UTC)[reply]

If you mean file systems on flash drives: it depends on the filesystem that you have installed on the flash drive. You could install FAT on a flash drive (and people often do, since it's quite cross-platform), but flash drives could have essentially any filesystem type on them. 95.199.3.30 (talk) 23:33, 2 July 2022 (UTC)[reply]

The Limits section measures clusters and sections in "KB," but there's no such unit as a "KB." There are kB (1000 bytes) and KiB (1024 bytes). Please fix that by replacing "KB" with the correct unit. 91.193.176.8 (talk) 11:46, 14 November 2022 (UTC)[reply]

Beating a dead horse. It's been some time now when Wikipedia finally and fortunately accepted that everybody (except hard drive manufacturers) means 1024 when they discuss kilobytes. CapnZapp (talk) 15:49, 1 June 2023 (UTC)[reply]