Talk:File Allocation Table

Trouble about the writing style

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." يي يبيبيب — Preceding unsigned comment added by 37.106.29.217 (talk) 19:18, 16 December 2016 (UTC)

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)

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)

@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)

@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)

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)

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)

@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)

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)

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)

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)

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)

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)

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)

FATX Epoch

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)

problems with incorrect/inconsistent information presented

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"

problems

thereby blowing up dimensions, is probably not meant to be in this article can someone fix this???

External links modified

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)

External links modified

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)

External links modified

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)

still inuse (when?) answered

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)