![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | ← | Archive 4 | Archive 5 | Archive 6 |
Removed this paragraph
I agree with the comment elsewhere that the FAT article is not the place for a discussion of DOS.
But I removed this because in the presence of a MS DOS cache (which allowed defered writes), the 21-68 system call (commit file) would flush the cache.
This behaviour was different on Windows 98, but Win 98 did not use DOS for the file system. —Preceding unsigned comment added by 218.214.18.240 ( talk) 05:18, 18 September 2010 (UTC)
Article seems to need a a table or chart of Fat version, max partition size, cluster size. —Preceding unsigned comment added by 71.131.14.212 ( talk) 16:18, 14 October 2010 (UTC)
The table in section: http://en.wikipedia.org/wiki/File_Allocation_Table#Directory_table states about the attribute byte at offeset 0x0b in the directory entry about bit 6, mask 0x40: 'Device (internal use only, never found on disk)'. Well, it can be found on some disks, especially when the were formatted by me :-) I have found out that when Windows (NT or newer) finds a file with this attribute bit set, it completely denies access to this file -- reading, writing, executing, deletion or attribute change is completely prohibited by the kernel.
I think this is a very useful feature: all my memory sticks and FAT formatted external drives contain an empty file named 'autorun.inf' with this attribute set in the root directory. Some Windows systems are configured to run the autorun.inf file without even asking the user, which is a perfect way to infect the system with malware.
Maybe this behaviour should be mentioned somewhere in this article? -- 153.97.93.25 ( talk) 12:14, 17 December 2010 (UTC)
Under section 1.6 FAT32 the following should be completely removed from the article:
Additionally, there are numerous reports that the DOS scandisk utility provided with Windows 98 (scandisk.exe) and even Windows 98 itself can in fact operate on FAT32 volumes with cluster counts much higher than the 4.177 million claimed by Microsoft, some of which have been in the 40 to 120 million range, thereby indicating that the scandisk utility can likely operate on volumes up to the upper limit of the FAT32 specifications.[18]
There are not numerous reports about this, this is a completely unsubstantiated claim made by one anonymous individual on a Usenet group. The individual has not presented his credentials and his test methodology or any verifiable reproducible test results. His proof lies in the simple claim that "I ran scandisk and it started and ran..." however he does not know what, if anything, that scandisk did and he doesn't know if scandisk examined all the files and clusters on the disk. The scandisk utility supplied with Windows 98 is a 16-bit application and due to immutable 16-bit memory block limits it simply cannot properly load the FAT to do a proper check if it contains more than 4,177,920 clusters, this is explained as such by Microsoft:
[Quote]
The ScanDisk tool included with Microsoft Windows 95 and Microsoft Windows 98 is a 16-bit program. Such programs have a single memory block maximum allocation size of 16 MB less 64 KB. Therefore, The Windows 95 or Windows 98 ScanDisk tool cannot process volumes using the FAT32 file system that have a FAT larger than 16 MB less 64 KB in size. A FAT entry on a volume using the FAT32 file system uses 4 bytes, so ScanDisk cannot process the FAT on a volume using the FAT32 file system that defines more than 4,177,920 clusters (including the two reserved clusters).
[end quote] http://support.microsoft.com/kb/184006
The poster's conclusion is that "...the scandisk utility can likely operate on volumes up to the upper limit of the FAT32 specifications...". In all likeliness the tests performed by the Usenet poster probably only loaded a truncated portion of the FAT or it may only have appeared to run properly while leaving a large portion of the disk unchecked. Without a verifiable test method the information in the post is specious at best. As a matter of fact, if one digs a bit in the same Usenet archive one will find that the claims of this particular poster have been questioned on several occasions, for example: ( http://groups.google.com/group/microsoft.public.win98.gen_discussion/browse_thread/thread/7bd36a399830299f/c5d72eb3d733d761?#c5d72eb3d733d761 ) and that the poster could not ever satisfactorily answer to his critics, this leaves me wondering as to why this information was ever inserted in the article and whom actually inserted this unproven information into the Wikipedia article to begin with.
Should we believe and trust the information provided by Microsoft or should we embark on a slippery slope and trust information made by anonymous unverifiable Usenet posters instead? It doesn't seem to me that Usenet posts made by single anonymous persons and containing no solidly verifiable source or citation would meet the high standards of accuracy required to make it in a Wikipedia article, these kind of unverified or unverifiable Usenet posts are highly dubious sources for any organization that strives to present accurate information to its readers. For these reasons I move that the information be stricken from the article.
MidnightTwo ( talk) 00:12, 17 June 2011 (UTC)
Section 1.6 contains the following:
"All versions of Windows prior to XP-SP1 and 2000-SP4 lacked inherent support for 48-bit LBA drive access because of a limitation in their 32-bit protected-mode IDE driver, ... "
Protected Mode Driver is terminology generally applied to hybrid Windows 9x operating systems, Windows NT operating systems are pure 32-bit operating systems and Protected Mode Driver is a redundant term when applied to these operating systems, the term is generally never used in the context of Windows NT operating system, on these systems they are simply drivers. This incorrect terminology also comes from the anonymous Usenet post claiming that scandisk runs properly on disks with more than 4,177,920 clusters.
Paragraphs 2, 3, 4 & 5 need to be removed or substantially pruned as they contain unproven or inaccurate and misleading information:
On Windows 95/98, due to the version of Microsoft's DOS-mode SCANDISK utility included with these operating systems being a 16-bit application, the FAT structure is not allowed to grow beyond 4 177 920 (< 222) clusters, placing the volume limit at 127.5 GiB (≈137 GB).[16][17] The FAT32 drive formatting tools provided by Microsoft (fdisk and format) are thus designed to scale the cluster size upwards as the volume size increases, thereby preventing the cluster-count from exceeding 4.177 million clusters - and only reaching that number on volumes with a size of 128 GB with 32 kB cluster size. Most or all appraisals of the efficiency of the FAT32 file system are rooted in this behavior, as they point out that FAT32 increases the cluster size with the volume size and therefore small file storage can become very inefficient when larger cluster sizes are used (eg - 32 kB). This behavior, however, is unnecessary in many cases. Large FAT32 volumes can in fact be created with smaller cluster sizes (eg 4 kB) given the use of alternate drive preparation tools.
Additionally, there are numerous reports that the DOS scandisk utility provided with Windows 98 (scandisk.exe) and even Windows 98 itself can in fact operate on FAT32 volumes with cluster counts much higher than the 4.177 million claimed by Microsoft, some of which have been in the 40 to 120 million range, thereby indicating that the scandisk utility can likely operate on volumes up to the upper limit of the FAT32 specifications.[18] A limitation in original versions of Windows 98/98SE's Fdisk utility causes it to incorrectly report disk sizes over 64 GiB.[19] A corrected version is available from Microsoft, but it cannot partition drives larger than 512 GiB (≈550 GB).[20]
Windows 98 (and presumably Windows ME) has been shown to be able to run from and correctly operate with volumes exceeding 128 GB (up to 1.5 TB in some reports) as well as with FAT32 volumes with 40 to 120 million clusters, although the native drive maintenance tools (scandskw.exe, defrag) have upper limits that are not yet known - but are reported to exceed 20 million clusters when using Windows ME versions of these tools. The installation program and filesystem creation tool supplied with Windows 2000, XP, and later imposes a limitation of 32 GiB.[21] However, these systems can read and write to FAT32 file systems of any size. This limitation is by design and according to Microsoft was imposed because many tasks on a very large FAT32 file system become slow and inefficient.[16][22] This limitation can be bypassed by using third-party formatting utilities or by using the FORMAT command with the /FS:FAT32 switch from the command line.[23]
All versions of Windows prior to XP-SP1 and 2000-SP4 lacked inherent support for 48-bit LBA drive access because of a limitation in their 32-bit protected-mode IDE driver, meaning that the maximum disk size for (parallel) ATA disks is 128 GiB (≈137 GB),[24] without using alternate drivers. Windows XP became fully 48-bit LBA capable with SP1 in 2002, but Microsoft did not release a patch for the 32-bit protected-mode drivers for Windows 98/ME (ESDI_506.PDR) even though those OS's were still being fully supported by Microsoft at that time. Intel did release an alternate IDE driver for win-9x/me (Intel Application Accelerator) that provides full 48-bit LBA operability for the 800-series chipsets, and several individuals and user groups have modified Microsoft's EDSI_506.PDR driver to make it 48-bit LBA compliant for Windows 98. Most or all third-party drivers for SATA controllers are 48-bit LBA compliant, even when used under Windows 98/ME. All versions of DOS that are FAT-32 aware are also 48-bit LBA capable, so long as 48-bit LBA is supported by the underlying hardware (ie - motherboard / BIOS).
In particular this statement in paragraph 2:
The FAT32 drive formatting tools provided by Microsoft (fdisk and format) are thus designed to scale the cluster size upwards as the volume size increases, thereby preventing the cluster-count from exceeding 4.177 million clusters - and only reaching that number on volumes with a size of 128 GB with 32 kB cluster size. Most or all appraisals of the efficiency of the FAT32 file system are rooted in this behavior, as they point out that FAT32 increases the cluster size with the volume size and therefore small file storage can become very inefficient when larger cluster sizes are used (eg - 32 kB). This behavior, however, is unnecessary in many cases. Large FAT32 volumes can in fact be created with smaller cluster sizes (eg 4 kB) given the use of alternate drive preparation tools.
This is grossly inaccurate. While it is true that larger clusters lead to less efficient storage space the main inefficiency on large FAT32 volumes does not come from the larger cluster size but rather it comes from the large cluster count and the ridiculously large FAT structure required to keep track of it all, as explained by Raymond Chen:
[Quote]
FAT used linear searching and threaded file allocation information in a linked list. All these linear-time data structures were acceptable when the FAT file system was developed—at a time when floppy drives were the primary storage device. Today, however, multi-gigabyte drives are the norm and these linear-time algorithms fall apart due to the large amount of disk access required to carry out a single operation. Furthermore, the high cluster count means a ridiculously large file allocation table; as a result, even the simple act of computing how much free disk space is available can take over a minute. That’s why the first time you type the dir command, there is a long pause at the end of the directory listing: the file system is busy calculating the disk free space to display at the bottom of the directory listing. [end quote]
This is also touched on here: http://www.pcguide.com/ref/hdd/file/partFAT32-c.html
This FAT size affect performance because of the linear manner in which the FAT is accessed and processed whereas the high count of smaller 4K cluster isn't a concern on the NTFS MFT B-tree structure.
The paragraphs in question also demonstrate a poor technical writing style which is not in keeping with Wikipedia's high standards, for example:
All versions of Windows prior to XP-SP1 and 2000-SP4...
A more appropriate construction would be:
All Windows versions prior to Windows 2000 SP4 and Windows XP SP1... The writing style in the section pales when compared to other similar Wikipedia articles such as http://en.wikipedia.org/wiki/Windows_2000 and http://en.wikipedia.org/wiki/Windows_XP
And of course it goes without saying that the information in the above statement is also incorrect! Support for 48-bit LBA became available for Windows 2000 with Service Pack 3, not SP4!
In another paragraph the writer states:
"Windows 98 (and presumably Windows ME) has been shown..."
Another glaring example of writing or information which is not in keeping with Wikipedia's high standards. Technically correct information doesn't run on "presumptions", it runs on accurate and verifiable information, none of which is present in Paragraphs 2, 3, 4 & 5, .
Much of the information in section 1.6 was edited and added by a single person and includes information from citation 18, all of the information from this specious source needs to be revisited and confirmed by knowledgeable persons or it need to be stricken from the article. On second thought, all of it needs to be removed, period! It is all bogus and without supporting citations, a complete fabrication from a single anonymous Usenet poster!
MidnightTwo ( talk) 01:39, 17 June 2011 (UTC)
Removed factually incorrect self published information on June 22, 2011
~~ (broken signature apparently for
MidnightTwo)
Whomever wrote "The maximum possible size for a file on an FAT32 volume is 4 GB minus 1 byte or 4,294,967,295 (232−1) bytes." made a mistake. That amount of bytes equals 1 GiB, not 1 GB. — Preceding unsigned comment added by 77.54.85.108 ( talk) 21:32, 2 January 2013 (UTC)
Please merge the FATX stub into the corresponding subsection here, a "fresher" epoch instead of 1980-01-01 does not justify a separate article. – 89.204.137.133 ( talk) 21:47, 17 July 2011 (UTC)
An assessment of this article was requested. I have tagged the article as being too technical for most readers to access. I have started to move some of the technical minutia to the new Notes section. I have lowered the assessment from B to C. -- Kvng ( talk) 22:23, 5 December 2011 (UTC)
This passage is a particular offender: The name originates from the usage of a table which centralizes the information about which areas belong to files, are free or possibly unusable, and where each file is stored on the disk. To limit the size of the table, disk space is allocated to files in contiguous groups of hardware sectors called clusters.
Not only is this extremely vague if you don't already understand what file systems do, it's flat wrong: the whole point of the linked allocation scheme used in FAT is that the clusters allocated to a file do not have to be (and often aren't) contiguous!
Valency ( talk) 23:28, 10 December 2011 (UTC)
It would be nice to step back...way back...and give a bit of an overview of the consequences of the FAT file system. Files on disk grow in cluster-size chunks, so you want small clusters. You only have 12, 16, or 32 bits in each FAT entry, so you want big clusters for big disk drives. Clusters can be anywhere on the disk, so after a while the "cluster chain" weaves all over the disk surface, causing the notorious file fragmentation (hands up, everyone who ever ran defrag utilities? Keep your hands up if defrag ran overnight?). It's a singly-linked list, so if you lose one cluster in the chain, you lose the rest of the file. If you zero out a directory entry and lose the pointer to the first cluster of a file, that file space gets orphaned and can't be reused until some utility program notices that there's a chain with no corresponding directory entry - the so called "lost clusters" which CHKDSK would try to turn into files for you. You erase a file by setting all its FAT entries to 0, marking them as free space...even though the data is still in the sectors, you've destroyed the mapping into a file. This is why you can still read data on an erased disk. There's FAT in memory and FAT on the disk and woe betide you if you pull the disk out before its copy of the FAT has been synchronized with the copy in memory. Etc. Let's get the lay of the forest before we start reciting the names of the caterpillars on the leaves of the trees. We all too quickly get into details of Binford 6100 DOS and its all-Roman-numeral file naming convention...
We also have very long and detailed technical comments hidden in commented-out text inside the infobox. If this is important, it should be in a table or in the main text somewhere and visible - and referenced. -- Wtshymanski ( talk) 05:25, 7 January 2012 (UTC)
Recently revisions to the infobox content have "date_resolution = 2 seconds (10 ms with VFAT)". I thought granularity of access timestamp was 1 day and of modification timestamp was 2s, even in recent formats, and I cannot find any smaller-granularity fields in the revised tables in File Allocation Table#Directory table. The 10ms VFAT refinement seems to apply only to creation timestamp. Should the infobox entry be changed?
If so, then I would also suggest that finer modification timestamp granularity (and also recording of UTC timezone offsets) are two advantages of exFAT over FAT32, contrary to the statement that in File Allocation Table#exFAT that exFAT "offers no practical benefits over FAT32".
I also thought that exFAT has cluster alignment characteristics better suited to the large internal storage block sizes of solid-state drives.
— Richardguk ( talk) 06:25, 23 December 2011 (UTC)
This is now a book-length article. Isn't it time to move all the fascinating details to a Wikibook and make this into an encyclopedia overview? -- Wtshymanski ( talk) 14:21, 12 January 2012 (UTC)
I actually came to this page to find these "fascinating details". James Murray 80.176.88.36 ( talk) 12:15, 16 January 2012 (UTC)
![]() | Material from File Allocation Table/Archive 6 was split to File Allocation Table(variants) on 2012 Feb 8. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted so long as the latter page exists. Please leave this template in place to link the article histories and preserve this attribution. |
Hydradix ( talk) 10:05, 8 February 2013 (UTC)
![]() | Material from File Allocation Table/Archive 6 was split to FAT_(reserved sectors) on 2012 Feb 9. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted so long as the latter page exists. Please leave this template in place to link the article histories and preserve this attribution. |
Hydradix ( talk) 15:28, 9 February 2013 (UTC)
How many Files can go into a FAT-x-directory? -- Itu ( talk) 18:29, 4 February 2012 (UTC)
The FAT+ draft is a good idea, almost obvious: There is only one problem with huge 4GB+ files, the length doesn't fit into 32 bits for directory entries. Therefore grab some normally unused bits in directory entries for longer files, and pray that software unaware of this feature doesn't clobber huge files. Black magic such as read-only attributes or an unofficial FAT32 version 0.1 instead of 0.0 might help. However, this draft is unfinished original research, and shouldn't be referenced everywhere in the article. I've removed or trimmed some references, keeping them as is where they were on topic and relevant. A better idea might be to list FAT+ in the FATX + exFAT section, and remove all references elsewhere. – 89.204.130.222 ( talk) 18:04, 3 December 2012 (UTC)
I've never heard of it. And after reading the fatplus.txt it sounds like a good, but private idea. So I ask: Is FAT+ implemented in some major operating system and/or used by embedded devices like video cameras etc.? (Btw, the fact that the FAT+ "inventors" just claim a new "version" of the FAT32. That can and will collide when the "official FAT specificatior" will define a new version.) -- RokerHRO ( talk) 23:31, 2 January 2014 (UTC)
Somebody reintroduced the 4078 cruft for FAT12. This was eliminated in 2011, because it is obviously in conflict with all published standards (two ECMA versions, identical ISO versions, and Microsoft's own FAT32 UEFI specification.) If for some unknown reason historical DOS 3.3 and additional versions really treated 0xFF0 as an additional end of chain mark in some contexts, it might be one of many historical bugs, because eight standard end of chain marks 0xFF8 up to 0xFFF should be more than good enough. One of the authors here apparently thinks or knows that 0xFF0 is special, because it could be confused with media descriptor 0xF0 at the begin of the FATs (non-existing clusters 0 and 1.) That's an interesting theory, please add a reference to an external online source, e.g., a page number visible with Google Books or similar. – 82.113.98.229 ( talk) 04:32, 4 December 2012 (UTC)
Split - Article is over 200 kB, and should be split out, starting with "Historical Evolution" and "Technical design". Thoughts? Suggestions?-- Jax 0677 ( talk) 18:42, 31 December 2012 (UTC)
Direct experimentation with DOS 1.XX images (available in the Internet) revealed, that catalog entries, staring (or even filled) with 0x00 are treated as files (without name, date, and with zero size). 0xE5 is used as marker of unused entries. (In fact, code does only simple comparison: "CMP BYTE PTR [BX],0E5H", followed by "jz" )
So statement (in corresponding table, http://en.wikipedia.org/wiki/File_Allocation_Table#Directory_entry ) is wrong: 0x00 "Entry is available and no subsequent entry is in use. Also serves as an end marker when DOS scans a directory table. (Since MS-DOS/PC DOS 1.0, but not in 86-DOS)." and should be written as: 0x00 "Entry is available and no subsequent entry is in use. Also serves as an end marker when DOS scans a directory table. (Since MS-DOS/PC DOS 2.0, but not in 86-DOS or MS-DOS/PC DOS 1.XX)." and some comment about it for 0xE5 should be added.
But, I have almost zero experience in writing wiki articles. All things above are, in fact, original research, though easy repeatable by anyone. And I do not know any reliable sources, (except disk images itself), which describe that anomaly of early DOS. — Preceding unsigned comment added by Indrekis ( talk • contribs) 05:17, 4 March 2013 (UTC)
"As some TomTom products are based on Linux, this marked the first time that Microsoft tried to enforce its patents against the Linux platform"
The lawsuit was against TomTom, not against the Open Source community and the interpretation of the lawsuit is the personal opinion of Ryan Paul. It appears to sound more like this: SOME ARGUE that this marked the first time that Microsoft tried to enforce its patents against the Linux platform.
The edit doesn't make sense and clearly shows a bias against Microsoft. The lawsuit was against a company which made several products that read and write FAT32 and infringed more than two(2) of M$ patents, not because some TomTom products are Linux based and can read/write FAT...
Ryan Paul's
analysis
"
If Microsoft attempts to broadly enforce this patent against Linux users and vendors, the Open Invention Network (OIN) might decide to invoke the so-called "nuclear option" and retaliate with its own massive arsenal of software patents"--
FaustoLG (
talk)
02:49, 23 April 2013 (UTC)
I think values for for 8-inch floppy (500.5 KiB) with Media descriptor 0xFD are not correct, although same values are published on Microsoft help site. A FAT with 6 sectors a 128 Bytes gives 768 Bytes. This divided by 1.5 for FAT12 gives 512 FAT entries. With a cluster size of 4 sectors only less than 2048 sectors can addressed, That is very much smaller then the about 4004 sectors. JJenderek ( talk) 17:58, 13 June 2013 (UTC)
5/6 of the article is about technical details about FAT. Can we move that somewhere else please? 68.111.85.224 ( talk) 04:15, 10 July 2013 (UTC)
Matthiaspaul, I don't think we can discount the many voices that have complained (sometimes unconstructively) about the current state of this article. You yourself have acknowledged that there is a problem and have indicated that the work I was doing was so far the best proposal for improving things. Let's not let perfect be the enemy of good here. The pressing need is to make this article more accessible to more casual readers.
An alternative to splitting out the history section would be to remove 4/5ths of the content in this chapter. I believe deletion on that scale would be controversial so a split is preferred. We can add a better summary of the history to the main article. I think a table of FAT variants would be appropriate in this article, for instance. Questions about where redirects point can be resolved as we proceed. I believe it is impractical to plan out everything in advance. ~ KvnG 13:26, 16 May 2014 (UTC)
The "Boot sector" section states that "For backward compatibility MS-DOS, PC DOS and DR-DOS also accept a jump (0x69 0x?? 0x??)" with 3 references. Well, 0x69 is not a Jump instruction, but an IMUL. That's not even a valid op-code for the 8086, it is supported from 386. And I think this instruction is 4-bytes length, which is 1 byte longer than the location where it has to be stored. [1] 79.152.196.39 ( talk) 17:29, 30 August 2013 (UTC)
... cmp bl,0E9h ; does it start with a JMP? je login_media40 cmp bl,069h je login_media40 cmp bl,0EBh ; how about a JMPS? jne login_media10 cmp al,090h ; then we need a NOP je login_media40 login_media10: ; get FAT ID here ... login_media40: ...
I propose to cut the article into two articles, one for FAT32 and later implementations, and one for FAT16 and older. Cogiati ( talk) 23:40, 19 November 2013 (UTC)
"removable media (with the exception of CDs and DVDs)" can be written more correctly as "random access removable media", if you do not count DVD-RAM, (which also supports FAT32) and tape-based storages. -- 84.236.52.141 ( talk) 17:14, 4 January 2014 (UTC)
I've been doing a research project for my PC Repair class, and I've noticed that there is no information on compatibility with the NTFS (its predecessor) nor is there any type of compatibility section in this article. I think the inclusion of such section would be nice for technicians. Thanks. -LetsBeChillx 72.10.125.1 ( talk) 14:04, 6 March 2014 (UTC)
Dear experts (I'm not one): I still have a use for Iomega's zip disks as a way to move data to and from an ancient computer running Windows 98. Today I tried hooking an old Zip drive (100 MB, external, connecting via USB) to my Mac running OS X 10.6. I was pleased to discover that the disk mounted & seems to work on the Mac. Out of curiosity, I looked at the disk's properties as shown by the Mac's Disk Utility. It says Format: MS-DOS (FAT-16). As a Mac guy, I don't know much about FATs. Also, Wikipedia's Original Research says I shouldn't edit articles based on such discoveries. So I ask: Somewhere in at least 1 of these 2 articles (FAT and Zip drive), please mention that FAT-16 is a format for 100 MB Zip disks, and provide a reference. (Assuming this is correct!) By the way, Zip disks also supported Apple's old HFS file system, but HFS isn't useful to move data to/from modern Macs, let alone to/from DOS etc. Oaklandguy ( talk) 02:39, 12 March 2014 (UTC)
I'm not sure how we should fix it, but I feel as if the article is far too long. Maybe the technical details or the exFAT information could be split into new articles? What do you think we could do to minimize the article's size? Sofia Koutsouveli ( talk) 22:51, 17 March 2014 (UTC)
Where can I find the original 8-bit FAT specification? Benhut1 ( talk) 23:33, 3 May 2014 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
There have been numerous comments dating back to January 2012 or further on this talk page regarding length and detail in this article. In February I proposed that a good start towards addressing these issues would be to split out the Historical evolution and Technical design sections into File Allocation Table historical evolution and File Allocation Table technical design articles respectively, and leaving a summary of each in this article. Seeing good support, I started implementing the proposal this month. The work in progress was reverted and further work has been halted.
I would like comments on whether this work should resume or do we need to allow more time for additional planning and discussion before making changes. ~ KvnG 02:06, 20 May 2014 (UTC)
Comment: Only here for the RfC. In general I don't feel very strongly about long vs short articles as long as the structure suits the topic. Here however, I reckon that the structure DOES in fact suit separation into shorter, cross-linked articles, so much so that I don't understand why there should be any debate. Nor can I in the time I have available follow the discussion. The best I can do (sorry!) is to say: "Guys, this article is on an important topic and is nearly useless as it stands. Split it, tidy it up and do everyone a favour." Good luck to the saner elements! JonRichfield ( talk) 11:08, 21 May 2014 (UTC)
Oppose and Alternative suggestion: I'm somewhat unhappy with the wording how Kvng advertised this RfC in other locations, because it can easily lead to wrong conclusions, but anyway. What I reverted was a badly carried out split attempt before finishing discussions and building consensus (at least in my judgement), but I very much welcome any constructive discussions and contributions to this article.
While I don't personally support the split, I already gave in to it to address the size issue (the new split-out article exists under
Design of the FAT file system and I prepared a cut-down and fixed up version of the old article under
[1], but not activated it so far, since I haven't received feedback to the discussion above yet and many of the incoming links are still not fixed up at present (WIP). Therefore, this article no longer has any size issues.
I continue to oppose splitting out the history stuff (at least at this stage), though, because this information really belongs into an article about the File Allocation Table, and I think it is easy enough to read even for casual readers. We must keep some interesting information here also for readers already familiar with the FAT file system. Splitting this out, there would be basically no useful information left except for some trivial fluff for beginners. So far, Knvg has not contributed contents to the article nor has he illustrated what he has in mind for the article. Therefore, at this stage, it would be premature to split out even more. Depending on if and what will be added to the article to fill the gapping voids, now, that the technical stuff has been splitting out, we might reconsider the idea somewhen in the future. But I think, it should be possible for any new contents to be arranged so that it can be nicely integrated with the existing stuff (for suggestions, see discussion further above). We'll see... --
Matthiaspaul (
talk) 14:54, 21 May 2014 (UTC) (Updated to avoid confusion, as the split-out was activated later on 2014-05-21.
Matthiaspaul (
talk)
14:39, 27 May 2014 (UTC))
Oppose: I think the information belongs in the article itself - it will be unnecessarily complicated for a reader to click on another article to get the history of the article when the information is there. That's why you have a navigation menu bar - you can click on what section you want to go to. -- JustBerry ( talk) 15:17, 24 May 2014 (UTC)
Support - Do split history into a separate article. The history section is too long to be a single section in a longer article and should be in its own article, with a very brief summary in the main article. Personally I feel it should be called File Allocation Table History, deleting the evolution, as it is, in my opinion, implicit that it would have evolved over time.
The rest of technical design should be moved to the new article, with (again) a very brief summary in the main article.
Edit: Since my comments the article has changed in structure, becoming historical evolution (in all but name), emphasising the need to separate the technical and historical information. It is hard to obtain either a technical or historical overview as there is no link to a technical design section, while history is embedded in technical information. I reiterate my suggestion for a summary section on both the technical and historical aspects of FAT. 15:52, 28 May 2014 (UTC)
mthinkcpp ( talk) 11:43, 23 May 2014 (UTC)
Alternative suggestion Since you both agree now on splitting out at least the technical section, why not do that first, and (if there's no objections) delete altogether some of the trivia from history (like "borrowing the FAT concept for SCP's own 8086 operating system QDOS 0.10") and then see what the article looks like? Rolf H Nelson ( talk) 23:36, 25 May 2014 (UTC)
Oppose deletions on procedural basis. Just go slow and do more discussion and mitigation for now. While I am not much at this page, I will offer my 2 cents: I agree the size is an issue, but that seems outweighed by wanting the process right -- (1) have the split pages before any cuts are tried and (2) an article that been developed over a long time and is large should have a similarly long discussion period and any major change needs a major consensus. There has been progress working around the size by some split off pages and there could be more and more work on outline letting people get to just the part they want, so it seems like work is ongoing and should get more time and talk and if you still want amputation then have the split content existing before deleting content here. Markbassett ( talk) 23:02, 6 June 2014 (UTC)
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | ← | Archive 4 | Archive 5 | Archive 6 |
Removed this paragraph
I agree with the comment elsewhere that the FAT article is not the place for a discussion of DOS.
But I removed this because in the presence of a MS DOS cache (which allowed defered writes), the 21-68 system call (commit file) would flush the cache.
This behaviour was different on Windows 98, but Win 98 did not use DOS for the file system. —Preceding unsigned comment added by 218.214.18.240 ( talk) 05:18, 18 September 2010 (UTC)
Article seems to need a a table or chart of Fat version, max partition size, cluster size. —Preceding unsigned comment added by 71.131.14.212 ( talk) 16:18, 14 October 2010 (UTC)
The table in section: http://en.wikipedia.org/wiki/File_Allocation_Table#Directory_table states about the attribute byte at offeset 0x0b in the directory entry about bit 6, mask 0x40: 'Device (internal use only, never found on disk)'. Well, it can be found on some disks, especially when the were formatted by me :-) I have found out that when Windows (NT or newer) finds a file with this attribute bit set, it completely denies access to this file -- reading, writing, executing, deletion or attribute change is completely prohibited by the kernel.
I think this is a very useful feature: all my memory sticks and FAT formatted external drives contain an empty file named 'autorun.inf' with this attribute set in the root directory. Some Windows systems are configured to run the autorun.inf file without even asking the user, which is a perfect way to infect the system with malware.
Maybe this behaviour should be mentioned somewhere in this article? -- 153.97.93.25 ( talk) 12:14, 17 December 2010 (UTC)
Under section 1.6 FAT32 the following should be completely removed from the article:
Additionally, there are numerous reports that the DOS scandisk utility provided with Windows 98 (scandisk.exe) and even Windows 98 itself can in fact operate on FAT32 volumes with cluster counts much higher than the 4.177 million claimed by Microsoft, some of which have been in the 40 to 120 million range, thereby indicating that the scandisk utility can likely operate on volumes up to the upper limit of the FAT32 specifications.[18]
There are not numerous reports about this, this is a completely unsubstantiated claim made by one anonymous individual on a Usenet group. The individual has not presented his credentials and his test methodology or any verifiable reproducible test results. His proof lies in the simple claim that "I ran scandisk and it started and ran..." however he does not know what, if anything, that scandisk did and he doesn't know if scandisk examined all the files and clusters on the disk. The scandisk utility supplied with Windows 98 is a 16-bit application and due to immutable 16-bit memory block limits it simply cannot properly load the FAT to do a proper check if it contains more than 4,177,920 clusters, this is explained as such by Microsoft:
[Quote]
The ScanDisk tool included with Microsoft Windows 95 and Microsoft Windows 98 is a 16-bit program. Such programs have a single memory block maximum allocation size of 16 MB less 64 KB. Therefore, The Windows 95 or Windows 98 ScanDisk tool cannot process volumes using the FAT32 file system that have a FAT larger than 16 MB less 64 KB in size. A FAT entry on a volume using the FAT32 file system uses 4 bytes, so ScanDisk cannot process the FAT on a volume using the FAT32 file system that defines more than 4,177,920 clusters (including the two reserved clusters).
[end quote] http://support.microsoft.com/kb/184006
The poster's conclusion is that "...the scandisk utility can likely operate on volumes up to the upper limit of the FAT32 specifications...". In all likeliness the tests performed by the Usenet poster probably only loaded a truncated portion of the FAT or it may only have appeared to run properly while leaving a large portion of the disk unchecked. Without a verifiable test method the information in the post is specious at best. As a matter of fact, if one digs a bit in the same Usenet archive one will find that the claims of this particular poster have been questioned on several occasions, for example: ( http://groups.google.com/group/microsoft.public.win98.gen_discussion/browse_thread/thread/7bd36a399830299f/c5d72eb3d733d761?#c5d72eb3d733d761 ) and that the poster could not ever satisfactorily answer to his critics, this leaves me wondering as to why this information was ever inserted in the article and whom actually inserted this unproven information into the Wikipedia article to begin with.
Should we believe and trust the information provided by Microsoft or should we embark on a slippery slope and trust information made by anonymous unverifiable Usenet posters instead? It doesn't seem to me that Usenet posts made by single anonymous persons and containing no solidly verifiable source or citation would meet the high standards of accuracy required to make it in a Wikipedia article, these kind of unverified or unverifiable Usenet posts are highly dubious sources for any organization that strives to present accurate information to its readers. For these reasons I move that the information be stricken from the article.
MidnightTwo ( talk) 00:12, 17 June 2011 (UTC)
Section 1.6 contains the following:
"All versions of Windows prior to XP-SP1 and 2000-SP4 lacked inherent support for 48-bit LBA drive access because of a limitation in their 32-bit protected-mode IDE driver, ... "
Protected Mode Driver is terminology generally applied to hybrid Windows 9x operating systems, Windows NT operating systems are pure 32-bit operating systems and Protected Mode Driver is a redundant term when applied to these operating systems, the term is generally never used in the context of Windows NT operating system, on these systems they are simply drivers. This incorrect terminology also comes from the anonymous Usenet post claiming that scandisk runs properly on disks with more than 4,177,920 clusters.
Paragraphs 2, 3, 4 & 5 need to be removed or substantially pruned as they contain unproven or inaccurate and misleading information:
On Windows 95/98, due to the version of Microsoft's DOS-mode SCANDISK utility included with these operating systems being a 16-bit application, the FAT structure is not allowed to grow beyond 4 177 920 (< 222) clusters, placing the volume limit at 127.5 GiB (≈137 GB).[16][17] The FAT32 drive formatting tools provided by Microsoft (fdisk and format) are thus designed to scale the cluster size upwards as the volume size increases, thereby preventing the cluster-count from exceeding 4.177 million clusters - and only reaching that number on volumes with a size of 128 GB with 32 kB cluster size. Most or all appraisals of the efficiency of the FAT32 file system are rooted in this behavior, as they point out that FAT32 increases the cluster size with the volume size and therefore small file storage can become very inefficient when larger cluster sizes are used (eg - 32 kB). This behavior, however, is unnecessary in many cases. Large FAT32 volumes can in fact be created with smaller cluster sizes (eg 4 kB) given the use of alternate drive preparation tools.
Additionally, there are numerous reports that the DOS scandisk utility provided with Windows 98 (scandisk.exe) and even Windows 98 itself can in fact operate on FAT32 volumes with cluster counts much higher than the 4.177 million claimed by Microsoft, some of which have been in the 40 to 120 million range, thereby indicating that the scandisk utility can likely operate on volumes up to the upper limit of the FAT32 specifications.[18] A limitation in original versions of Windows 98/98SE's Fdisk utility causes it to incorrectly report disk sizes over 64 GiB.[19] A corrected version is available from Microsoft, but it cannot partition drives larger than 512 GiB (≈550 GB).[20]
Windows 98 (and presumably Windows ME) has been shown to be able to run from and correctly operate with volumes exceeding 128 GB (up to 1.5 TB in some reports) as well as with FAT32 volumes with 40 to 120 million clusters, although the native drive maintenance tools (scandskw.exe, defrag) have upper limits that are not yet known - but are reported to exceed 20 million clusters when using Windows ME versions of these tools. The installation program and filesystem creation tool supplied with Windows 2000, XP, and later imposes a limitation of 32 GiB.[21] However, these systems can read and write to FAT32 file systems of any size. This limitation is by design and according to Microsoft was imposed because many tasks on a very large FAT32 file system become slow and inefficient.[16][22] This limitation can be bypassed by using third-party formatting utilities or by using the FORMAT command with the /FS:FAT32 switch from the command line.[23]
All versions of Windows prior to XP-SP1 and 2000-SP4 lacked inherent support for 48-bit LBA drive access because of a limitation in their 32-bit protected-mode IDE driver, meaning that the maximum disk size for (parallel) ATA disks is 128 GiB (≈137 GB),[24] without using alternate drivers. Windows XP became fully 48-bit LBA capable with SP1 in 2002, but Microsoft did not release a patch for the 32-bit protected-mode drivers for Windows 98/ME (ESDI_506.PDR) even though those OS's were still being fully supported by Microsoft at that time. Intel did release an alternate IDE driver for win-9x/me (Intel Application Accelerator) that provides full 48-bit LBA operability for the 800-series chipsets, and several individuals and user groups have modified Microsoft's EDSI_506.PDR driver to make it 48-bit LBA compliant for Windows 98. Most or all third-party drivers for SATA controllers are 48-bit LBA compliant, even when used under Windows 98/ME. All versions of DOS that are FAT-32 aware are also 48-bit LBA capable, so long as 48-bit LBA is supported by the underlying hardware (ie - motherboard / BIOS).
In particular this statement in paragraph 2:
The FAT32 drive formatting tools provided by Microsoft (fdisk and format) are thus designed to scale the cluster size upwards as the volume size increases, thereby preventing the cluster-count from exceeding 4.177 million clusters - and only reaching that number on volumes with a size of 128 GB with 32 kB cluster size. Most or all appraisals of the efficiency of the FAT32 file system are rooted in this behavior, as they point out that FAT32 increases the cluster size with the volume size and therefore small file storage can become very inefficient when larger cluster sizes are used (eg - 32 kB). This behavior, however, is unnecessary in many cases. Large FAT32 volumes can in fact be created with smaller cluster sizes (eg 4 kB) given the use of alternate drive preparation tools.
This is grossly inaccurate. While it is true that larger clusters lead to less efficient storage space the main inefficiency on large FAT32 volumes does not come from the larger cluster size but rather it comes from the large cluster count and the ridiculously large FAT structure required to keep track of it all, as explained by Raymond Chen:
[Quote]
FAT used linear searching and threaded file allocation information in a linked list. All these linear-time data structures were acceptable when the FAT file system was developed—at a time when floppy drives were the primary storage device. Today, however, multi-gigabyte drives are the norm and these linear-time algorithms fall apart due to the large amount of disk access required to carry out a single operation. Furthermore, the high cluster count means a ridiculously large file allocation table; as a result, even the simple act of computing how much free disk space is available can take over a minute. That’s why the first time you type the dir command, there is a long pause at the end of the directory listing: the file system is busy calculating the disk free space to display at the bottom of the directory listing. [end quote]
This is also touched on here: http://www.pcguide.com/ref/hdd/file/partFAT32-c.html
This FAT size affect performance because of the linear manner in which the FAT is accessed and processed whereas the high count of smaller 4K cluster isn't a concern on the NTFS MFT B-tree structure.
The paragraphs in question also demonstrate a poor technical writing style which is not in keeping with Wikipedia's high standards, for example:
All versions of Windows prior to XP-SP1 and 2000-SP4...
A more appropriate construction would be:
All Windows versions prior to Windows 2000 SP4 and Windows XP SP1... The writing style in the section pales when compared to other similar Wikipedia articles such as http://en.wikipedia.org/wiki/Windows_2000 and http://en.wikipedia.org/wiki/Windows_XP
And of course it goes without saying that the information in the above statement is also incorrect! Support for 48-bit LBA became available for Windows 2000 with Service Pack 3, not SP4!
In another paragraph the writer states:
"Windows 98 (and presumably Windows ME) has been shown..."
Another glaring example of writing or information which is not in keeping with Wikipedia's high standards. Technically correct information doesn't run on "presumptions", it runs on accurate and verifiable information, none of which is present in Paragraphs 2, 3, 4 & 5, .
Much of the information in section 1.6 was edited and added by a single person and includes information from citation 18, all of the information from this specious source needs to be revisited and confirmed by knowledgeable persons or it need to be stricken from the article. On second thought, all of it needs to be removed, period! It is all bogus and without supporting citations, a complete fabrication from a single anonymous Usenet poster!
MidnightTwo ( talk) 01:39, 17 June 2011 (UTC)
Removed factually incorrect self published information on June 22, 2011
~~ (broken signature apparently for
MidnightTwo)
Whomever wrote "The maximum possible size for a file on an FAT32 volume is 4 GB minus 1 byte or 4,294,967,295 (232−1) bytes." made a mistake. That amount of bytes equals 1 GiB, not 1 GB. — Preceding unsigned comment added by 77.54.85.108 ( talk) 21:32, 2 January 2013 (UTC)
Please merge the FATX stub into the corresponding subsection here, a "fresher" epoch instead of 1980-01-01 does not justify a separate article. – 89.204.137.133 ( talk) 21:47, 17 July 2011 (UTC)
An assessment of this article was requested. I have tagged the article as being too technical for most readers to access. I have started to move some of the technical minutia to the new Notes section. I have lowered the assessment from B to C. -- Kvng ( talk) 22:23, 5 December 2011 (UTC)
This passage is a particular offender: The name originates from the usage of a table which centralizes the information about which areas belong to files, are free or possibly unusable, and where each file is stored on the disk. To limit the size of the table, disk space is allocated to files in contiguous groups of hardware sectors called clusters.
Not only is this extremely vague if you don't already understand what file systems do, it's flat wrong: the whole point of the linked allocation scheme used in FAT is that the clusters allocated to a file do not have to be (and often aren't) contiguous!
Valency ( talk) 23:28, 10 December 2011 (UTC)
It would be nice to step back...way back...and give a bit of an overview of the consequences of the FAT file system. Files on disk grow in cluster-size chunks, so you want small clusters. You only have 12, 16, or 32 bits in each FAT entry, so you want big clusters for big disk drives. Clusters can be anywhere on the disk, so after a while the "cluster chain" weaves all over the disk surface, causing the notorious file fragmentation (hands up, everyone who ever ran defrag utilities? Keep your hands up if defrag ran overnight?). It's a singly-linked list, so if you lose one cluster in the chain, you lose the rest of the file. If you zero out a directory entry and lose the pointer to the first cluster of a file, that file space gets orphaned and can't be reused until some utility program notices that there's a chain with no corresponding directory entry - the so called "lost clusters" which CHKDSK would try to turn into files for you. You erase a file by setting all its FAT entries to 0, marking them as free space...even though the data is still in the sectors, you've destroyed the mapping into a file. This is why you can still read data on an erased disk. There's FAT in memory and FAT on the disk and woe betide you if you pull the disk out before its copy of the FAT has been synchronized with the copy in memory. Etc. Let's get the lay of the forest before we start reciting the names of the caterpillars on the leaves of the trees. We all too quickly get into details of Binford 6100 DOS and its all-Roman-numeral file naming convention...
We also have very long and detailed technical comments hidden in commented-out text inside the infobox. If this is important, it should be in a table or in the main text somewhere and visible - and referenced. -- Wtshymanski ( talk) 05:25, 7 January 2012 (UTC)
Recently revisions to the infobox content have "date_resolution = 2 seconds (10 ms with VFAT)". I thought granularity of access timestamp was 1 day and of modification timestamp was 2s, even in recent formats, and I cannot find any smaller-granularity fields in the revised tables in File Allocation Table#Directory table. The 10ms VFAT refinement seems to apply only to creation timestamp. Should the infobox entry be changed?
If so, then I would also suggest that finer modification timestamp granularity (and also recording of UTC timezone offsets) are two advantages of exFAT over FAT32, contrary to the statement that in File Allocation Table#exFAT that exFAT "offers no practical benefits over FAT32".
I also thought that exFAT has cluster alignment characteristics better suited to the large internal storage block sizes of solid-state drives.
— Richardguk ( talk) 06:25, 23 December 2011 (UTC)
This is now a book-length article. Isn't it time to move all the fascinating details to a Wikibook and make this into an encyclopedia overview? -- Wtshymanski ( talk) 14:21, 12 January 2012 (UTC)
I actually came to this page to find these "fascinating details". James Murray 80.176.88.36 ( talk) 12:15, 16 January 2012 (UTC)
![]() | Material from File Allocation Table/Archive 6 was split to File Allocation Table(variants) on 2012 Feb 8. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted so long as the latter page exists. Please leave this template in place to link the article histories and preserve this attribution. |
Hydradix ( talk) 10:05, 8 February 2013 (UTC)
![]() | Material from File Allocation Table/Archive 6 was split to FAT_(reserved sectors) on 2012 Feb 9. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted so long as the latter page exists. Please leave this template in place to link the article histories and preserve this attribution. |
Hydradix ( talk) 15:28, 9 February 2013 (UTC)
How many Files can go into a FAT-x-directory? -- Itu ( talk) 18:29, 4 February 2012 (UTC)
The FAT+ draft is a good idea, almost obvious: There is only one problem with huge 4GB+ files, the length doesn't fit into 32 bits for directory entries. Therefore grab some normally unused bits in directory entries for longer files, and pray that software unaware of this feature doesn't clobber huge files. Black magic such as read-only attributes or an unofficial FAT32 version 0.1 instead of 0.0 might help. However, this draft is unfinished original research, and shouldn't be referenced everywhere in the article. I've removed or trimmed some references, keeping them as is where they were on topic and relevant. A better idea might be to list FAT+ in the FATX + exFAT section, and remove all references elsewhere. – 89.204.130.222 ( talk) 18:04, 3 December 2012 (UTC)
I've never heard of it. And after reading the fatplus.txt it sounds like a good, but private idea. So I ask: Is FAT+ implemented in some major operating system and/or used by embedded devices like video cameras etc.? (Btw, the fact that the FAT+ "inventors" just claim a new "version" of the FAT32. That can and will collide when the "official FAT specificatior" will define a new version.) -- RokerHRO ( talk) 23:31, 2 January 2014 (UTC)
Somebody reintroduced the 4078 cruft for FAT12. This was eliminated in 2011, because it is obviously in conflict with all published standards (two ECMA versions, identical ISO versions, and Microsoft's own FAT32 UEFI specification.) If for some unknown reason historical DOS 3.3 and additional versions really treated 0xFF0 as an additional end of chain mark in some contexts, it might be one of many historical bugs, because eight standard end of chain marks 0xFF8 up to 0xFFF should be more than good enough. One of the authors here apparently thinks or knows that 0xFF0 is special, because it could be confused with media descriptor 0xF0 at the begin of the FATs (non-existing clusters 0 and 1.) That's an interesting theory, please add a reference to an external online source, e.g., a page number visible with Google Books or similar. – 82.113.98.229 ( talk) 04:32, 4 December 2012 (UTC)
Split - Article is over 200 kB, and should be split out, starting with "Historical Evolution" and "Technical design". Thoughts? Suggestions?-- Jax 0677 ( talk) 18:42, 31 December 2012 (UTC)
Direct experimentation with DOS 1.XX images (available in the Internet) revealed, that catalog entries, staring (or even filled) with 0x00 are treated as files (without name, date, and with zero size). 0xE5 is used as marker of unused entries. (In fact, code does only simple comparison: "CMP BYTE PTR [BX],0E5H", followed by "jz" )
So statement (in corresponding table, http://en.wikipedia.org/wiki/File_Allocation_Table#Directory_entry ) is wrong: 0x00 "Entry is available and no subsequent entry is in use. Also serves as an end marker when DOS scans a directory table. (Since MS-DOS/PC DOS 1.0, but not in 86-DOS)." and should be written as: 0x00 "Entry is available and no subsequent entry is in use. Also serves as an end marker when DOS scans a directory table. (Since MS-DOS/PC DOS 2.0, but not in 86-DOS or MS-DOS/PC DOS 1.XX)." and some comment about it for 0xE5 should be added.
But, I have almost zero experience in writing wiki articles. All things above are, in fact, original research, though easy repeatable by anyone. And I do not know any reliable sources, (except disk images itself), which describe that anomaly of early DOS. — Preceding unsigned comment added by Indrekis ( talk • contribs) 05:17, 4 March 2013 (UTC)
"As some TomTom products are based on Linux, this marked the first time that Microsoft tried to enforce its patents against the Linux platform"
The lawsuit was against TomTom, not against the Open Source community and the interpretation of the lawsuit is the personal opinion of Ryan Paul. It appears to sound more like this: SOME ARGUE that this marked the first time that Microsoft tried to enforce its patents against the Linux platform.
The edit doesn't make sense and clearly shows a bias against Microsoft. The lawsuit was against a company which made several products that read and write FAT32 and infringed more than two(2) of M$ patents, not because some TomTom products are Linux based and can read/write FAT...
Ryan Paul's
analysis
"
If Microsoft attempts to broadly enforce this patent against Linux users and vendors, the Open Invention Network (OIN) might decide to invoke the so-called "nuclear option" and retaliate with its own massive arsenal of software patents"--
FaustoLG (
talk)
02:49, 23 April 2013 (UTC)
I think values for for 8-inch floppy (500.5 KiB) with Media descriptor 0xFD are not correct, although same values are published on Microsoft help site. A FAT with 6 sectors a 128 Bytes gives 768 Bytes. This divided by 1.5 for FAT12 gives 512 FAT entries. With a cluster size of 4 sectors only less than 2048 sectors can addressed, That is very much smaller then the about 4004 sectors. JJenderek ( talk) 17:58, 13 June 2013 (UTC)
5/6 of the article is about technical details about FAT. Can we move that somewhere else please? 68.111.85.224 ( talk) 04:15, 10 July 2013 (UTC)
Matthiaspaul, I don't think we can discount the many voices that have complained (sometimes unconstructively) about the current state of this article. You yourself have acknowledged that there is a problem and have indicated that the work I was doing was so far the best proposal for improving things. Let's not let perfect be the enemy of good here. The pressing need is to make this article more accessible to more casual readers.
An alternative to splitting out the history section would be to remove 4/5ths of the content in this chapter. I believe deletion on that scale would be controversial so a split is preferred. We can add a better summary of the history to the main article. I think a table of FAT variants would be appropriate in this article, for instance. Questions about where redirects point can be resolved as we proceed. I believe it is impractical to plan out everything in advance. ~ KvnG 13:26, 16 May 2014 (UTC)
The "Boot sector" section states that "For backward compatibility MS-DOS, PC DOS and DR-DOS also accept a jump (0x69 0x?? 0x??)" with 3 references. Well, 0x69 is not a Jump instruction, but an IMUL. That's not even a valid op-code for the 8086, it is supported from 386. And I think this instruction is 4-bytes length, which is 1 byte longer than the location where it has to be stored. [1] 79.152.196.39 ( talk) 17:29, 30 August 2013 (UTC)
... cmp bl,0E9h ; does it start with a JMP? je login_media40 cmp bl,069h je login_media40 cmp bl,0EBh ; how about a JMPS? jne login_media10 cmp al,090h ; then we need a NOP je login_media40 login_media10: ; get FAT ID here ... login_media40: ...
I propose to cut the article into two articles, one for FAT32 and later implementations, and one for FAT16 and older. Cogiati ( talk) 23:40, 19 November 2013 (UTC)
"removable media (with the exception of CDs and DVDs)" can be written more correctly as "random access removable media", if you do not count DVD-RAM, (which also supports FAT32) and tape-based storages. -- 84.236.52.141 ( talk) 17:14, 4 January 2014 (UTC)
I've been doing a research project for my PC Repair class, and I've noticed that there is no information on compatibility with the NTFS (its predecessor) nor is there any type of compatibility section in this article. I think the inclusion of such section would be nice for technicians. Thanks. -LetsBeChillx 72.10.125.1 ( talk) 14:04, 6 March 2014 (UTC)
Dear experts (I'm not one): I still have a use for Iomega's zip disks as a way to move data to and from an ancient computer running Windows 98. Today I tried hooking an old Zip drive (100 MB, external, connecting via USB) to my Mac running OS X 10.6. I was pleased to discover that the disk mounted & seems to work on the Mac. Out of curiosity, I looked at the disk's properties as shown by the Mac's Disk Utility. It says Format: MS-DOS (FAT-16). As a Mac guy, I don't know much about FATs. Also, Wikipedia's Original Research says I shouldn't edit articles based on such discoveries. So I ask: Somewhere in at least 1 of these 2 articles (FAT and Zip drive), please mention that FAT-16 is a format for 100 MB Zip disks, and provide a reference. (Assuming this is correct!) By the way, Zip disks also supported Apple's old HFS file system, but HFS isn't useful to move data to/from modern Macs, let alone to/from DOS etc. Oaklandguy ( talk) 02:39, 12 March 2014 (UTC)
I'm not sure how we should fix it, but I feel as if the article is far too long. Maybe the technical details or the exFAT information could be split into new articles? What do you think we could do to minimize the article's size? Sofia Koutsouveli ( talk) 22:51, 17 March 2014 (UTC)
Where can I find the original 8-bit FAT specification? Benhut1 ( talk) 23:33, 3 May 2014 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
There have been numerous comments dating back to January 2012 or further on this talk page regarding length and detail in this article. In February I proposed that a good start towards addressing these issues would be to split out the Historical evolution and Technical design sections into File Allocation Table historical evolution and File Allocation Table technical design articles respectively, and leaving a summary of each in this article. Seeing good support, I started implementing the proposal this month. The work in progress was reverted and further work has been halted.
I would like comments on whether this work should resume or do we need to allow more time for additional planning and discussion before making changes. ~ KvnG 02:06, 20 May 2014 (UTC)
Comment: Only here for the RfC. In general I don't feel very strongly about long vs short articles as long as the structure suits the topic. Here however, I reckon that the structure DOES in fact suit separation into shorter, cross-linked articles, so much so that I don't understand why there should be any debate. Nor can I in the time I have available follow the discussion. The best I can do (sorry!) is to say: "Guys, this article is on an important topic and is nearly useless as it stands. Split it, tidy it up and do everyone a favour." Good luck to the saner elements! JonRichfield ( talk) 11:08, 21 May 2014 (UTC)
Oppose and Alternative suggestion: I'm somewhat unhappy with the wording how Kvng advertised this RfC in other locations, because it can easily lead to wrong conclusions, but anyway. What I reverted was a badly carried out split attempt before finishing discussions and building consensus (at least in my judgement), but I very much welcome any constructive discussions and contributions to this article.
While I don't personally support the split, I already gave in to it to address the size issue (the new split-out article exists under
Design of the FAT file system and I prepared a cut-down and fixed up version of the old article under
[1], but not activated it so far, since I haven't received feedback to the discussion above yet and many of the incoming links are still not fixed up at present (WIP). Therefore, this article no longer has any size issues.
I continue to oppose splitting out the history stuff (at least at this stage), though, because this information really belongs into an article about the File Allocation Table, and I think it is easy enough to read even for casual readers. We must keep some interesting information here also for readers already familiar with the FAT file system. Splitting this out, there would be basically no useful information left except for some trivial fluff for beginners. So far, Knvg has not contributed contents to the article nor has he illustrated what he has in mind for the article. Therefore, at this stage, it would be premature to split out even more. Depending on if and what will be added to the article to fill the gapping voids, now, that the technical stuff has been splitting out, we might reconsider the idea somewhen in the future. But I think, it should be possible for any new contents to be arranged so that it can be nicely integrated with the existing stuff (for suggestions, see discussion further above). We'll see... --
Matthiaspaul (
talk) 14:54, 21 May 2014 (UTC) (Updated to avoid confusion, as the split-out was activated later on 2014-05-21.
Matthiaspaul (
talk)
14:39, 27 May 2014 (UTC))
Oppose: I think the information belongs in the article itself - it will be unnecessarily complicated for a reader to click on another article to get the history of the article when the information is there. That's why you have a navigation menu bar - you can click on what section you want to go to. -- JustBerry ( talk) 15:17, 24 May 2014 (UTC)
Support - Do split history into a separate article. The history section is too long to be a single section in a longer article and should be in its own article, with a very brief summary in the main article. Personally I feel it should be called File Allocation Table History, deleting the evolution, as it is, in my opinion, implicit that it would have evolved over time.
The rest of technical design should be moved to the new article, with (again) a very brief summary in the main article.
Edit: Since my comments the article has changed in structure, becoming historical evolution (in all but name), emphasising the need to separate the technical and historical information. It is hard to obtain either a technical or historical overview as there is no link to a technical design section, while history is embedded in technical information. I reiterate my suggestion for a summary section on both the technical and historical aspects of FAT. 15:52, 28 May 2014 (UTC)
mthinkcpp ( talk) 11:43, 23 May 2014 (UTC)
Alternative suggestion Since you both agree now on splitting out at least the technical section, why not do that first, and (if there's no objections) delete altogether some of the trivia from history (like "borrowing the FAT concept for SCP's own 8086 operating system QDOS 0.10") and then see what the article looks like? Rolf H Nelson ( talk) 23:36, 25 May 2014 (UTC)
Oppose deletions on procedural basis. Just go slow and do more discussion and mitigation for now. While I am not much at this page, I will offer my 2 cents: I agree the size is an issue, but that seems outweighed by wanting the process right -- (1) have the split pages before any cuts are tried and (2) an article that been developed over a long time and is large should have a similarly long discussion period and any major change needs a major consensus. There has been progress working around the size by some split off pages and there could be more and more work on outline letting people get to just the part they want, so it seems like work is ongoing and should get more time and talk and if you still want amputation then have the split content existing before deleting content here. Markbassett ( talk) 23:02, 6 June 2014 (UTC)