Talk:File Allocation Table

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Microsoft Windows / Computing  (Rated C-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Microsoft Windows, a collaborative effort to improve the coverage of Microsoft Windows on Wikipedia.
C-Class article C  Quality: C-Class
 Mid  Importance: Mid
Taskforce icon
This article is supported by WikiProject Computing.

Trouble about the writing style[edit]

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)

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:
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[edit]

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[edit]

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 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"


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