Talk:File Allocation Table/Archive 6

Archive 1

←

Archive 4

Archive 5

Archive 6

Fragmentation - flush to disk

Removed this paragraph

MS-DOS also did not offer a system call which would allow applications to make sure a particular file has been completely written to disk in the presence of deferred writes (cf. fsync in Unix or DosBufReset in OS/2). Disk caches on MS-DOS were operating on disk block level and were not aware of higher-level structures of the file system. In this situation, cheating with regard to the real progress of a disk operation was most dangerous.

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)

Need a table or chart of FAT version, max. partition size, cluster size

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)

Done. Took me some hours, because I didn't know that FAT12 hex. FF6 + FAT16 hex. FFF6 are not the maximal cluster numbers, but reserved. Now it's your turn, transform the stupid preformatted size limits into a proper wikitable... :-) –89.204.137.161 (talk) 01:55, 4 July 2011 (UTC)

At some point in time the article should settle on the arguably correct FF5 / FFF5 / 0FFF FFF5 limits instead of the more obscure FF0 / FFF0 / 0FFF FFF0 limits for FAT12 / FAT16 / FAT32, respectively. IIRC the ...0 limits existed for Amiga (or something), so that is no patent nonsense. But nevertheless it can't be "correct", otherwise there would be "impossible" maximal cluster numbers FF1..FF5 / FFF1..FFF5 / 0FFF FFF1 .. 0FFF FFF5 not discussed in the standards. –82.113.99.129 (talk) 15:03, 14 July 2011 (UTC)

The highest officially allowed data cluster is 0xBF (8-bit FAT) / 0xFEF (FAT12) / 0xFFEF (FAT16) / 0x0FFFFFEF (FAT32). Higher clusters are either used for special purposes or are reserved from former use or for future use. While some operating systems try to cope with somewhat higher data cluster numbers as well (sometimes conditionally only), such volumes are non-standard and should -by all means- not be created, because many implementations may not be able to work with them and may cause serious data corruption. --Matthiaspaul (talk) 13:56, 25 May 2014 (UTC)

A less known feature of the file attribute byte

The table in section: http://wiki.riteme.site/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)

If somebody has a reference for this feature, e.g., if Ralf Brown's Interrupt List mentions it, please add it. –82.113.99.129 (talk) 14:51, 14 July 2011 (UTC)

This "feature" goes back to MS-DOS/PC DOS already. It is used internally to distinguish files from character devices (which, depending on the system's AVAILDEV status, may be mapped in as "virtual files" in any directory). The bit is never set on the physical disk though. If you manage to set it anyway, the kernel will assume the file in question is a (non-existing) character device, that's why it may have problems accessing it. I don't think it is documented by Microsoft, but I seem to remember that I have seen it being described in one of the "undocumented" books. You can also confirm its existance using a debugger or disassembler. --Matthiaspaul (talk) 13:56, 25 May 2014 (UTC)

FAT32 - DOS SCANDISK utility

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]

Reason

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)

If you find errors please just be bold and fix them. It's a wiki, undo/revert are simple. –82.113.99.129 (talk) 15:13, 14 July 2011 (UTC)

FAT32 - Improper terminology (and more factual errors!)

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://wiki.riteme.site/wiki/Windows_2000 and http://wiki.riteme.site/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)

JFTR, protected mode is proper Intel or x86 (above 80186) or OS/2 terminology, but as you said it makes no sense for NT drivers, as there are no real mode or VxD drivers for NT — not counting NTVDM 16bit character mode DOS drivers. Writing "presumably ME" is sloppy, but features introduced in win 98 in fact presumably also exist in win ME. Not talking about it might be better than using a weasel word, but it's no evidence for nonsense. Likewise "2000-SP4" or "XP-SP1" is not the best style, but otherwise clear, and by itself no evidence for nonsense. If there are any FAT32 limits below 2 TB I'm interested in verified technical details. –82.113.99.129 (talk) 16:06, 14 July 2011 (UTC)

Maximum file size

Whomever wrote "The maximum possible size for a file on an FAT32 volume is 4 GB minus 1 byte or 4,294,967,295 (2³²−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)

Not taking the FAT32+ extension (which allows file sizes up to 2³⁸−1 = 256 GiB - 1 bytes) into account, the maximum file size is 2³²−1 = 4 GiB - 1 bytes, if the volume is large enough (therefore possible on FAT16X, FAT32, FAT32X only) and the operating system supports so called "large files" API functions. If not, the maximum size is 2³¹−1 = 2 GiB - 1 bytes.

The reason why you saw "GB" instead of "GiB" is because the Manual of Style (MOS) of the English Wikipedia recommends not to use SI prefixes unless it is absolutely necessary to help avoid misunderstandings. Nevertheless, someone changed the prefixes to SI prefixes some while ago, and since nobody changed it back there appears to be a local consensus that using the SI prefixes is actually beneficial in this article.

--Matthiaspaul (talk) 13:56, 25 May 2014 (UTC)

FATX

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)

Done. Two references (Linux Xbox project) resulted in a server error today, please check this. –89.204.152.53 (talk) 03:44, 16 August 2011 (UTC)

I'm not sure it was a good idea to merge the articles, since FATX (FATX16 and FATX32) are different enough from FAT16 and and FAT32 to make it impossible to sufficiently describe them in this article. The "basic ideas" are the same, but most of the data structures are different, so FATX should really have it's own article in order not to confuse people (and also to avoid confusion with FAT16X and FAT32X, the official names for FAT16 and FAT32 partition IDs to enforce usage of LBA instead of CHS or mixed CHS/LBA access). I think it is okay to have a short abstract in the FAT article (as we have right now for FATX and exFAT), but better details should be discussed in separate articles. --Matthiaspaul (talk) 19:32, 9 January 2012 (UTC)

Technical

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!

I am working on a substantial rewrite. I agree the article can be made far more layman accessible and much of the technical information can be displaced to a notes section.

Valency (talk) 23:28, 10 December 2011 (UTC)

Actually, the sectors within a cluster are contiguous -- though the clusters within a file might not be... AnonMoos (talk) 16:31, 11 December 2011 (UTC)

Well, that's another issue: it confuses sectors with clusters! A cluster is a kind of allocation unit, but a sector in this context usually means the smallest addressable storage unit on a disk (or other storage medium), whereas a "cluster" in FAT terminology is the smallest addressable storage unit within the file system, and may be composed of several (yes, contiguous) hardware sectors. As it is, the reader is told a cluster is a kind of sector, itself composed of sectors, and that it's a "hardware sector", when in fact it's sectors that are hardware sectors, clusters are are software (file system) unit, which are called "clusters" to avoid confusion with hardware sectors, and each cluster is made up of several hardware sectors... you can see the problem!

Still working on that revision. -- Valency (talk) 06:56, 12 December 2011 (UTC)

We shouldn't use the term "hardware sectors" (whatever that may be) here. In the context of many PC operating systems, the allocatable units below the file system driver, as offered by the disk device driver, are so called logical sectors. The allocatable units as they are used by the driver working on the system BIOS INT 13h CHS or LBA interface or directly on the disk I/O hardware interface are called physical sectors. File systems don't normally deal with physical sectors. The device driver translates and optionally combines physical sectors into logical sectors for the file system to use. Logical sectors can have the same size as physical sectors, but can also be larger. In the case of a volume on a non-partitioned medium, accessed via LBA, (a so called "super-floppy") the logical and physical sector numbers can be the same (except for nomenclature that physical CHS sector numbers at BIOS INT 13h level start with sector 1, whereas physical LBA sectors at BIOS INT 13h level as well as logical sector numbers start with number 0), otherwise they differ.

I assume by "hardware sector" the original author meant physical sectors, but perhaps he even meant the "on-medium" sectors inside the drive which are typically somewhat larger (for parity/ECC info, etc.) and may be organized quite differently internally.

For FAT volumes, logical sectors may have sizes of 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192 or 16384 bytes. Some broken file system implementations can only deal with logical sectors of 512 bytes, though. On PC compatible machines, logical sector sizes below 512 bytes are seldomly used. 128 byte physical sectors could be found on some archaic floppy disks, and on PC compatible machines they are typically only found on small memory drives. Even on memory drives, logically sector sizes below 128 bytes are extremely rare (I have seen them only in lab conditions). Logical sector sizes larger than 512 bytes have once been very important to overcome the volume size limits before the introduction of FAT16B with DOS 3.31. There have been various OEM DOS 2.x/3.x versions, which worked with so called logical sectored FATs. On these systems, the physical sector size was still 512 bytes, but the device driver combined them into larger logical sectors for the file system driver to work with. The downside of this approach has been significantly increased memory consumption for the sector buffering inside the device driver (however, this is no issue for operating systems which are not bound to run in real mode any more).

Larger physical sector sizes than 512 bytes have been used on various optical drives (however, most of the time not formatted with a FAT file system), but they have become important again in recent years, as physical sector sizes are increasing beyond 512 bytes (at present up to 4096 bytes). --Matthiaspaul (talk) 11:19, 12 December 2011 (UTC)

I have reworked the offending section to hopefully give a better idea of why the filesystem is named FAT and how it works in general, without going into implementation specific details. --Matthiaspaul (talk) 20:46, 11 December 2011 (UTC)

Thanks for your effort, this is much better in terms of accuracy, but now I think it's too much of an infodump to go at the top of the page. In my draft I just say:

The FAT file system derives its name from its central structure, the File Allocation table, which uses linked allocation to keep track of the storage space allocated to each file.

and leave the technical details for later. I'm new at editing, and I'm not quite ready to work the live article yet, but I would move this at the least. --Valency (talk) 07:07, 12 December 2011 (UTC)

Hm, but your description would apply to most any file system, don't you think? I find it quite important to describe what is "special" about FAT compared to other file systems.

While it is always good to make something easier accessible to anyone, a layman will ever only get a very basic understanding of what it is and how it works, unless he really dedicates time and energy to actually understand the inner workings and over time gets an idea of the various implications. Risking that not everyone will be able to understand everything, some degree of technical detail will be unavoidable in an article about a file system, I think.

In fact, I find the article in its current form rather superficial with lots of things presented inaccurately and some important details missing. This article may give enough information to help someone find a lost file on a FAT volume on a mainstream PC, however, it does not discuss essentails for someone who would want to implement a FAT repair tool or a FAT driver, so that it becomes fully compatible with all existing FAT volumes in the wild, I'm afraid. --Matthiaspaul (talk) 12:40, 12 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)

Date resolution

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)

I noticed that too, but was waiting for the flurry of article updates to subside before looking in detail. You summarize the time precision I last found in the references and have implemented in my FAT drivers. exFAT, in my opinion, does not belong here. —EncMstr (talk) 06:49, 23 December 2011 (UTC)

That's right. Thanks for spotting this. 10ms resolution is only for creation time, which is an optional part of the specs. Last modified time resolution is still 2s, access date is still dates only.

Regarding exFAT, I agree, except for a small intro it does not belong into this FAT article, because exFAT is considerably different in many ways. It really is a filesystem of its own, and already has its own article, anyway. --Matthiaspaul (talk) 09:47, 23 December 2011 (UTC)

Thanks for the feedback and for updating both articles. — Richardguk (talk) 12:37, 23 December 2011 (UTC)

Length

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)

Though I'm in awe of the article's 100% expansion in the last two months, the fact remains that the content that average readers would be looking for (a readable description of the subject's unique properties, history and impact on the world) is completely swamped by technical detail. I literally cannot think of an analogue to this article elsewhere on the encyclopedia in terms of how much implementational detail it provides, such as that this page would seem to serve as an adequate reference document for implementing said file system for oneself. In the long run this really does belong in a wikibook. Chris Cunningham (user:thumperward) (talk) 16:44, 1 February 2012 (UTC)

I wouldn't be awestruck by an agglomeration of minutia, that's what we do best here on Jimbo's dream. Good luck finding out what a "lost cluster" is from all this, or why we even need CHKDSK or SCANDISK if FAT is such a perfect file system. 212 kB is about 200 kB too long and is preposterous for an encyclopedia overview of a failry unimportant topic. --Wtshymanski (talk) 19:28, 1 February 2012 (UTC)

You are making it quite difficult to find the constructive bits in your sarcastic assertions... I recognize and try to value this as your specific type of humor, but have you ever considered that your down-playing comments on other people's work might hurt someone? Not even because of the issues you raise (although I do not agree with all of them), but because of the derogative tone. While I'm not here for flowers, the article was tagged for expert attention, and I certainly have put a considerable amount of energy into fixing the many issues this article had (and still has to some degree). Actually, it bugged me for years, that Wikipedia was spreading so much incomplete, misleading and partially false information in regard to the FAT filesystem.

We may like it or not, but among filesystems, FAT may be the single most important family of filesystems of the past 30+ years; I'm not aware of any other filesystem in use for such a long time, implemented on so many different systems or used more frequently, even today. Sure there are technically more advanced filesystems, but they are not without their own set of shortcomings (and, BTW, they too suffer from levels of fragmentation and need "CHKDSK-like" utilities to correct errors). I think, this makes the FAT article a rather important article and it deserves to be a fully fleshed out article.

It's not that I would not recognize the "too technical" issue as well, but making this a reliable resource first had (and still has) a higher priority for me. I agree, that a laymen-compatible discussion of the basic concepts and consequences is still mostly missing, but this does in no way mean the other information would be unnecessary or unimportant. I will eventually address the "too technical" tag as well, unless someone else will have added the necessary introductory chapters since then (I envision them as 100% laymen-compatible sub-sections of the "Overview" chapter like "Basic concepts" and "Practical considerations" - and perhaps these intros could be brought into your hypothesized 12 KB "encyclopedia overview" - whereas a comprehensive encyclopedic description of the FAT file system meeting educational as well as professional standards simply cannot). Refactoring/recombining some distributed but related information, carefully reshaping the structure of chapters to make it easier to find the desired information, makeing the article's usage of the established technical vocabulary more stringent and consistent, and adding cross-references and notes to make interested readers aware of relations between certain entries, magic values or generic functionality, which are important to understand to fully comprehend the design of the FAT filesystem, have also been attempts to make this stuff more accessible to anyone actually interested in it. However, since I do not want to delete any valueable information, this is slow work, and I expect this to be several months more work before we will hopefully have reached the goal, that forward references are reduced to a minimum, all things are explained before used, and that the expected reader's level will grow from top to bottom, so that all information which might be interesting to laymen is located in the top half of the article and is fully accessible to them, while at the same time the article is comprehensive and accurate down to the details, so that it it also meets Wikipedia's goal to provide a reliable reference for experts.

If it would turn out that we cannot bring laymen and experts together in a single article, we might consider writing a seperate "Introduction to File Allocation Table" article as per Category:Introduction articles. However, I'm still optimistic that we do not need to resort to this.

In the very long run, it may be possible to move some of the information presented here into other articles such as Boot sector, Volume boot record or BIOS parameter block (which are all still very underdeveloped). However, there's a lot of stuff inhere, which is FAT-specific, and I am not sure if moving this stuff into other articles wouldn't compromise the quality of the articles. Therefore I won't explore this possibility until this article is "finished" and the information inflow has mostly stabilized. --Matthiaspaul (talk) 01:40, 2 February 2012 (UTC)

Too long (just like the article), didn't read. We're not here to improve our self esteem and hand out puppy pictures to each other; we're supposedly compiling the greatest encyclopedia the world has ever seen. Any non-trivial human endeavour is going to attract differences of opinion on how to proceed. --Wtshymanski (talk) 14:43, 2 February 2012 (UTC)

I agree, the article is way too long for the average reader. I think it should be split into seperate articles:

1. FAT variants (FAT-12, FAT-16(b), FAT-32, etc.) ** DONE **
2. FAT reserved sectors (boot sector, FS info, etc.) ** DONE **
3. FAT region (or FAT data structure)
4. FAT directory

of course this article would provide a summary of those components with links to the seperate articles Hydradix (talk) 07:26, 7 February 2013 (UTC)

Created split of variants (FAT-8,12,16,etc) and summarized history in this article (needs work)

Hydradix (talk) 10:05, 8 February 2013 (UTC)

I cleaned up References and Notes... but there is still an error relating to "NB_WIN98_WINCOM". I can not find it... so if you know how to fix it, then please do!!! Hydradix (talk) 10:34, 8 February 2013 (UTC)

Created split of reserved sectors (Boot sector, information sector, etc.) and summarized in this article (needs work)

Hydradix (talk) 15:28, 9 February 2013 (UTC)

Hi, sorry, but I have reverted back recent changes in order to ensure the high technical quality of this article before a consensus can be achieved here in regard to article splitting.

Unfortunately, I do not agree with your changes and while we will have to address the size issue of this article somewhen in the future, there is no reason to hurry, and there are IMO way more important things to do first (for example, writing the long planned "lay-man's intro chapter"). Before we split the article we should work out a plan, how exactly to do it, and then do it in a non-destructive matter.

This article, with much effort over the past one-and-a-half year or so, has reached a very high level of accuracy and I don't want to see all this hard work going down by ad-hoc editing.

I don't think, splitting out minor chapters is a good idea at all. I see at most two "natural breaks", where we could split, but at the expense of all carefully chosen internal cross-references no longer working and with a need to adjust hundreds of direct #hash links into the article from many external articles. So, we first need a good plan for this, as any change involves a huge amount of fixup work not only here but in many other articles as well. --Matthiaspaul (talk) 17:12, 9 February 2013 (UTC)

I think writing a condensed history with a link to details of the FAT variants is a good idea. Also splitting the four major parts of FAT file system (reserved sectors, FAT structure, directory, and data area) also seems to be an appropriate and natural way to reduce the size without loosing information. I realize there are several links that would need to be fixed and was planning to work on that today. Sorry you disagree. Who has a better suggestion? 98.93.24.118 (talk) 06:44, 11 February 2013 (UTC)

Remove excessive technical detail like the data structure layout and notes on obscure implementations. Summarise. Maybe transwiki, as suggested above. And it may obviate the need for a split altogether. This information may have a place somewhere, but Wikipedia is not it. It could be referenced as an item in the "External links" or "Further reading" section. Not put directly here. Keφr 07:41, 11 February 2013 (UTC)

How many files per directory?

How many Files can go into a FAT-x-directory? --Itu (talk) 18:29, 4 February 2012 (UTC)

What do you mean by "FAT-x"?

If you mean FAT12, FAT16 and FAT32 (proper spelling without hyphen), FAT12 and FAT16 have a format-specific limit of files for the root directory and no limit other than the maximum number of available data clusters elsewhere.

Format-specific means that the exact number depends on the type of media and how the volume was formatted. For older floppy formats (media descriptor other than F0h) there are fixed defaults and while they can be changed, Microsoft/IBM operating systems won't recognize the volume if the values don't reflect those used for a "standard format". For media descriptor type F0h, the value is more variable, but some operating systems still don't cope with non-default values for this entry. For harddisks, which typically have a media descriptor value of F8h, the number is set to 512 most of the time. Again, this value can be changed theoretically, but most operating systems won't be able to cope with non-default values here.

On FAT32 volumes, the root directory is not treated differently from other directories, therefore there is no limit on the number of files in the root up to the maximum number of available data clusters. Once again an exception: Microsoft documents a limit of 65534 on the number of files in a directory for FAT32, however, this is an artificial limit in their driver implementation, not in the specification of the FAT32 file system "as is". There are no such limits in other FAT32 implementations I am aware of, however, if you create volumes with more files in a directory, Microsoft operating systems won't be able to access them. Given that FAT becomes slow if you have several ten-thousand files in a single subdirectory (unless you have one of those "smart" implementations mentioned in the fragmentation chapter), it would be wise to split this up into several sub-directories, anyway.

I used the rather vague term "maximum number of available data clusters". The reason for this is that the exact number depends on various factors, the size and geometry of the volume (and to a limited amount the operating-system specific implementation of the filesystem), the number of files and directories in other directories, as well as their actual size, and finally the number of directory tables "used up" already (since they too are located in allocated clusters).

All numbers of files you may find listed somewhere refer to the number of directory entries and thereby to 8.3 short filenames, which occupy single directory entries only. Since VFAT long filenames occupy a variable number of additional directory entries per file (up to 20 extra entries, and theoretically up to 31 extra entries), their usage can significantly reduce those numbers. --Matthiaspaul (talk) 18:58, 4 February 2012 (UTC)

Thanks a lot. (yes i meant FAT12, FAT16, FAT32,.. but not interested in floppys )

Can this Information found somewhere in the article?

Im sure i got a limit of 20'000 files in a FAT-directory while operating with Linux and filenames of 20 characters some time ago. --Itu (talk) 20:26, 4 February 2012 (UTC)

Some of the info can be found in the article, some of it would still have to be added in the future.

Regarding your observation, has this been a FAT16 or a FAT32 volume? Do you remember the size of the volume and the cluster size used? Have there been any other files or directories on this particular volume when you tried to create this number of files in a particular subdirectory? How large were the files you created? Did they all had the same size? Did you mean 20000 to be a fixed number, when you ran into the problem, or did you mean "in the ballpark of 20000"? Which version of Linux, and which tool?

A 20 characters long filename will occupy three directory entries using VFAT, the entry for the short filename, and two VFAT entries for the long filename. --Matthiaspaul (talk) 21:14, 4 February 2012 (UTC)

FAT+

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)

Please ignore this suggestion, I used SoFixIt. –82.113.98.229 (talk) 04:37, 4 December 2012 (UTC)

Thank you very much, this article needed it. Would you consider creating an account? Keφr 05:50, 4 December 2012 (UTC)

Long story, I'm not going to use my new (2011) commons: + mw: account here, because I scrambled the password for old (2006) en:w: + m: + mediazilla: accounts beyond repair. ;-) –89.204.135.34 (talk) 17:35, 10 January 2013 (UTC)

is FAT+ relevant?

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)

FAT32+ is supported at least by some versions of DR-DOS and a number of applications. It is relevant because for some use-cases it represents a viable alternative to exFAT for files up to 256 GiB - 1 bytes on volumes up to 2 TiB in a mostly FAT32 backward-compatible way, that is easy to implement in other operating systems as well.

--Matthiaspaul (talk) 13:56, 25 May 2014 (UTC)

4078

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)

You were reverted because you introduced factually wrong information into the article.

Wikipedia does not require sources to be online, for as long as they are reliable. This isn't a "theory", but an easy to verify fact, even a documented one. Please visit your local library.

The reference implementation for FAT is that in DOS. If DOS can't cope with it, it isn't 100% compatible. (Just as the practical reference for NTFS is its implementation in Windows NT, etc.) You should not rely too much on those standards alone, as they unfortunately contain quite a large number of errors and omissions, making it next to impossible to implement a 100% compatible FAT driver based on the standards alone. In addition to this, you'll need a carefully selected mix of third-party documents as well (but mind that even many third-party books are full of errors, which is quite astonishing given that FAT is a rather simple file system by principle).

--Matthiaspaul (talk) 13:56, 25 May 2014 (UTC)

Size split?

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)

The article will certainly be better for not having the technical design section hhere. Best leave the rest of the article for now. Op47 (talk) 20:47, 8 February 2013 (UTC)

I think the page should be split between the different FAT systems, but there is a parent page on the generalities of the FAT system. For example, the parent page will include what the FAT system is, but it will include links to separate pages that talk about each specific system in detail. -LetsBeChillx 72.10.125.1 (talk) 13:09, 6 March 2014 (UTC)

Catalog entry, starting with 0x00, is not treated as unused by DOS 1.xx

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://wiki.riteme.site/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)

Thanks for the comment. Actually, it is a bit more complicated that this. Depending on where you look this is documented as "DOS 1 vs 86-DOS" or "DOS 2 and higher only". Truth is, it wasn't implemented in PC DOS 1.0 and 1.1 (which derived from MS-DOS 1.24), the first version of PC DOS to show this was 2.0. However, it was implemented in MS-DOS 1.25 (and higher). I had already improved the description several months ago, but have now reworked it to reflect this fact as well. --Matthiaspaul (talk) 12:18, 5 May 2014 (UTC)

Microsoft against the Open Source "Ryan Paul's analysis"

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

Unreasonable values for 8-inch floppy (500.5 KiB) with media descriptor 0xFD

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)

Your observation is correct, thanks for the hint! Microsoft's own reference documentation is seriously confused in regard to quite a few things to the extent of sometimes directly contradicting itself. In the hope that it will help to clear up the matter I added several references to the various numbers in order to indicate their origin. In this particular case, it seems as if they mixed up single-sided and double-sided media. However, since there is more than one possible combination of parameters, for us to rule out some of the documented values, we'd need to examine some 8-inch floppies created under MS-DOS 1.2x OEM versions. --Matthiaspaul (talk) 12:47, 5 May 2014 (UTC)

What is this huge thing in the middle?

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)

What should the article have as its majority contents then? One would expect some technical content in a technology article. Have you seen Global Positioning System, http, or NTFS? —EncMstr (talk) 16:58, 10 July 2013 (UTC)

How about we move some of those technical details to each of their own respective articles? At least in the articles you named, the technical details aren't so obvious, giant, and unreadable. 68.111.85.224 (talk) 06:19, 11 July 2013 (UTC)

Note how HTTP does not specify every single header defined in every single specification ever conceived. Note how NTFS or ext2 do not specify every single data structure they use down to the bit level (although they seem to be heading in this direction). Note how Portable Network Graphics does not specify the meaning of every single bit in every single chunk. Note how Global Positioning System does not specify, say, methods of signal modulation, error correction codes and NMEA 2000 fields… And all this is not because these articles are "incomplete", this is because of what Wikipedia articles ought to be. An encyclopedia article should not be a complete exposition of all possible details, but a summary of accepted knowledge regarding its subject. Keφr 11:06, 1 September 2013 (UTC)

I agree with Kephir & others: this article is much too long for easy use. The simplest solution would be to move the information about the history of FAT, & its technical description to sub-articles, replacing them with summary sections. That way users who want an introduction to the subject can quickly find the information, while those who need the gory details can procede to the sub-articles. This may not be the best solution, but it is an improvement on needing to download >200 kb of text to read anything about the subject. -- llywrch (talk) 17:09, 11 February 2014 (UTC)

I support splitting out the Historical evolution and Technical design sections and leaving a summary of each in this article. I have added {{Split section}} banners to the article. I propose File Allocation table historical evolution and File Allocation Table technical design as the respective destination articles. ~KvnG 16:43, 14 February 2014 (UTC)

I also support splitting historical variants and technical details to their own specialist pages. The tricky part is to write an appropriate summary of each section. There is already a phrase in the overview pointing to the history section: "FAT has a long history (over three decades) of usage…", which could then be linked directly to the new article. I also feel that the technical details are too involved even for a dedicated page; I would strongly advise to prune them per WP:NOTMANUAL. — JFG ^talk 10:01, 7 May 2014 (UTC)

I have done the split to File Allocation table historical evolution. I'll get around to the File Allocation Table technical design split when I get some more time. ~KvnG 22:32, 14 May 2014 (UTC)

I have reverted your move because your split-out was carried out badly leaving uncountable internal and external links dangling. So far, there is no consensus to do a split out at all, but even if we may do it somewhen in the future, there is absolutely no reason to hurry. It needs to be very carefully planned, agreed upon and then executed, ideally by someone who is familar with the article - it is my estimation that doing it properly will require days of dedicated work to fix up everything, nothing for drive-by editing.

I don't personally support the idea of splitting the article, because despite the template stating otherwise I don't believe that the current length creates any actual technical or navigational problems - splitting the contents over several articles will certainly create considerably more navigation problems, because the chapters are interwoven tightly and you would have to switch between the resulting sub-articles back and forth frequently (and, depending on the system and browser, you may need to reload the articles all the time). In fact, I have no problems to read and navigate the article even with archaic DOS web browsers running on 20+ year old hardware and with analog modem dialup. I can only guess what kind of problems people might have, but it can't be something technical - we're talking about a few hundred kilobytes in 2014, not megabytes.

Perhaps the problem is more down to that some readers are not really interested in the FAT file system and only need a very broad overview - and having their questions answered after reading the intro they might wonder, why they should read any further. The point is, they don't need to (that's why we start with the intro and overview section, and why for the most part the article becomes gradually more difficult to understand from the top to the bottom) - but they don't need to (and should not) complain either, because other people are interested in a more deep discussion and are actually searching for the very info provided in the remainder of the article. Wikipedia's goal is to be a reliable, highly accurate and comprehensive reference for anyone, laymen and experts - and anything between.

If so, a better solution to the problem might be to simply remove the template and complement this article by an easy-language introduction article like "Introduction to the FAT file system", as recommended for complex and possibly difficult to understand topics (such as the discussion of a filesystem); see Category:Introduction articles for more examples.

Actually, we were looking into expanding the current Overview section by a Concepts chapter discussing the file system in a very macroscopic and laymen-compatible way for more than 2.5 years now. Unfortunately, nobody has contributed anything in regard to this so far. I could certainly write such a chapter as well, but since this does not really need the attention of an expert on the subject, I hoped other's would jump on it sooner or later...

Regarding the split discussion, I would like to see important questions answered like what will we actually gain by splitting out contents. Just getting the technical stuff out of the eyes of some who don't care about or need that information shouldn't be a call for any drastic actions which may easily destroy a well-established and well-maintained article with a high number of page invocations. And splitting the article for no other purpose but to get rid of the automatically inserted template does not serve any purpose as well. There should be very good reasons, and the result should be a net gain for Wikipedia. So far, splitting out looks more like a loss for the project to me.

Another important question to be answered: If we move the history and technical stuff (which I consider the core of the article and the most important part) into other articles, what should be the contents of the remaining article? In my judgement, what would be left isn't what would belong into an article on the FAT file system, but more into an Introduction to the FAT file system article.

While having stated that I don't support the split in general, as I don't think it would benefit the project, I would also like to express, that I find your suggestion the most reasonable one so far - in fact, it comes close to what I had thought up as a possible alternative as well (except for the spelling of the titles) - but I'm not convinced so far. Therefore, if a split would be unavoidable in the long run, I would even offer to carry it out myself (when I find a time slot long enough to do it properly). As one of the article's main contributors, I am probably more familiar with most of the many embedded anchors and incoming links than anyone else, so it might help to minimize the damage.

--Matthiaspaul (talk) 02:14, 15 May 2014 (UTC)

I'm sorry I broke links to anchors - that was simply an oversight. (I actually noticed the issue as I started the split but after I had spent so much time carrying the right refs over, I had forgotten.) I'm an experienced editor and I think I'm up to the task. I was in the process of fixing the links when you reverted my changes again. I would like to finish that work. I don't think I have rushed into this. The discussion has been here for 9 months and until today there was the only support for the proposal.

I expect the first round of this work to produce only a minor net gain for the article. I am not changing any of the text, just adding a WP:SUMMARY for the split sections. I believe, however, that this work sets us up to make further improvements in a more reader-accessible way.

We're really going to need to do much of the same work whether we use an intro article or summary article. I am not doing this primarily because the article is too long. I'm doing it because the depth of coverage is inconsistent. This makes it hard for a reader to navigate. The stuff at the beginning and at the end is good general material. The stuff in the middle is very detailed and would largely only appeal to historians or programmers. ~KvnG 02:41, 15 May 2014 (UTC)

Actually, we (and this includes me, although I'm not fond of the idea, because I think a well-thought-out organization into chapters should be enough to split contents into sections not exceeding the attention spans of different audiences) are thinking about how to possibly reorganize and split the article for much longer, but so far nobody has come up with a really good proposal - in my judgement, your's was the best proposal so far, and it is at least partially (but only partially) in line with my own ideas; we might be able to put something really useful together on which we could agree upon. However, we don't need to hurry at all. The key point here is "together". I would assume that a particularly fruitful discussion about the development of the article emerges among those, who are deeply interested in and knowledgable about the subject, feel a need to change the status quo, and have already contributed some significant portion to the article. Since you haven't so far, I am somewhat sceptical, that (with all the best intentions) you may just cut the article into pieces as you see fit and without thinking about the long-term consequences, do some partial fix-up work (or none at all), and leave again - and thereby leave behind lots of dangling pointers and a messed up article without significant contents.

You state that there would have been only support for a split - I don't see that. It was mostly only by people who do not seem to have given much thought to the idea, its consequences and its alternatives. In fact, unfortunately, I have seen very few useful and constructive comments (your's and a few recent ones included) regarding this matter at all so far. Most were unconstructive remarks, foul language and even some ad-hominems - those people have ruled out themselves from being taken seriously, and this is not the type of discussion you will see me engaging in (and without being "forced" here, I would not comment under an unconstructive heading like "what's this huge thing in the middle?" as well (not only because I am one of the authors of "that huge thing in the middle", but also because such a comment shows clearly, that the commentor has no clue about the subject at all), in particular since I have already expressed my concerns earlier). Given, that this article has a high number of page invocations each day, the majority of people who read it seem to be happy with the contents and organization mostly. So, while it definitely isn't perfect, it can't be that bad to require really drastic immediate measures, either. There is always room for improvement, and I certainly see that. Given all the incomplete, misleading or downright faulty information about FAT file systems floating around in the net (and many books and original documentation), there are apparently not many people who are really experts on the subject. Therefore, over the past years, my primary focus was on complettness and accurancy in order to make this a highly reliable reference on which readers (including professionals in the field) can depend on. We still have years to come for necessary fine-tuning and to improve the prose.

Now, regarding your proposal, the more I think about it, the more I come to the conclusion that the history stuff cannot be reasonably splitted out of the article (at least not in the current state of the article). Without it, there's almost nothing left for the main article. You would have to rewrite everything, and in the end we would have redundant information in two or more parallel articles (and none of them being the suggested "introduction" article). Where should redirects like "FAT16" point to? To the main article, which no longer has any information about this particular file system, or to the history article, leaving readers puzzled about why they were redirected to a dedicated "history" article when they were looking up info about a particular file system variant? ... Further, while some readers may not be interested in history, this part is still reasonably easy to access, at least, if we assume someone would finally write the missing "Conceptual overview" chapter establishing the terms used in the history chapter. Finally, by stripping out this part, we won't gain much in regard to article size.

On the other hand, if the article gets the planned "Concepts" chapter, we could move the technical details (a more self-contained block, because it discusses FAT12/FAT16/FAT32 in one) to a new article like "Design of the FAT file system" without leaving the main article without a description of the file system at all (although it'll be useless for practical purposes). The chapters Fragmentation as well as Patents could remain in the main article as well, but possibly move elsewhere in the article. And redirects like "FAT16" would not have to be changed at all. The resulting structure for the main article could look similar to this:

• Intro
• Overview

• Concept

<Hatnote to main article on Design of the FAT file system article>

<very broad description of the file system, followed by a discussion of pros and cons>

• Uses
• Nomenclature

• Historical evolution

<unchanged>

• Fragmentation
• Legal matters / Patents

or

• Intro
• Overview

• Uses
• Nomenclature

• Historical evolution

<unchanged>

• Functional concept

• <Hatnote to main article on Design of the FAT file system article>

<very broad description of the file system, followed by a discussion of pros and cons>

• Fragmentation

• Legal matters / Patents

I hope to find more time on the weekend for further discussion.

--Matthiaspaul (talk) 11:23, 16 May 2014 (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)

I don't ignore complaints but I value them based on their quality, including usefulness of their proposal (if any), time and energy spent on the thought, as well as willingness and capability to participate in the development of an article. You can't write a fully-fledged article guided by the input of drive-by commenters, and while it can be sometimes helpful to point out weak spots, it is much more difficult to actually resolve issues than to complain about something. As much as we try, someone without a technical background simply cannot expect to be able to understand more than introductory chapters in a highly technical subject such as this one unless s/he's willing to really sit down and spent time and energy on it, whereas someone already familiar with the FAT file system on an advanced level will have absolutely no problems to read and fully comprehend the technical part even in the condensed language it is presented right now.

Some readers are overwhelmed by the level of detail in this article, still this is very far away from a listing of everything that exists under the sun, or a text book or manual. Whenever I added a detail or explanation I asked myself if it is an implicite part of the specification, necessary to know to implement a 100% compatible FAT file system driver or tool, or if I was seeking for an answer to that very question myself at some point in time. So, what might look like unnecessary detail to some, is necessary for the more interested people to fully understand the reasons why the file system was designed this way and not in another. It aims to fulfill Wikipedia's goal to be a dependable, comprehensive and highly accurate reference on a subject.

While we should strive to make an article as accessible as possible to anyone, there are limits. WP:TECHNICAL suggests to gradually increase the level from top to bottom. I think, over the past two years we've come a long way in ensuring this. The "Intro" and "Overview" chapters are trivially easy to understand, the "History" chapters, which outline some of the specifics of the various file system types and put them in context, are still easy to read but already require a reader interested in the subject, and the technical part is for advanced readers. It happens, that the "Fragmentation" and "Patents" chapters at the end of the article are easy-reading again, so following that strategy they could move further up in the article. They could, for example, become parts of the missing "Concepts" chapter or "Uses", but have been parked elsewhere because I didn't consider casual readers being particularly interested in them so far.

So much for accessibility and technical stuff. If you write you would remove 4/5 of the history part, you seem to have only a beginner's level audience in mind. Stripping this down to 1/5 would in fact be highly controversial. The result would be an easy-reading chapter without any actual information - nice for casual readers, but totally useless for any practical purposes. It could, however, belong into an introduction to the "History" part or into the "Overview" part, or into an "Introduction to the FAT file system"-type of article.

You stated that your primary motivation would be accessibility, not the size issue. If so, how about adding the 1/5 you have in mind, where you see fit (perhaps in front of the history chapter)? I would certainly consider this to be much more constructive for an editor who hasn't contributed to the article so far (except for two CEs) and doesn't want to plan in advance much than to come here and start by proposing to delete or move away virtually all the existing and long established contents other contributors have worked on for years. It may help other editors to get a feeling what you have in mind and if it will actually be an improvement for the article or not.

Regarding planing. Of course, we cannot plan everything in advance, but if we don't even try to lay out a plan, we'll likely have to go through multiple iterations, creating a huge amount of unnecessary work. In anticipation of a possible future restructuring of the contents I have created many redirects to aid maintenance when contents are moved around, however, there are many more embedded anchors used internally and in other articles, for which the creation of a redirect was not justified. The redirects already cover thousands of incoming links (and that's also, why it is important to know in advance where they should point to after reorganizing stuff), but there are still another 1500 direct links into this article (not counting the many external links from other sites which we cannot fix up, anyway). Whenever contents get moved around, they all will have to be checked carefully in order to ensure that they still point to the correct page and target anchor. If this massive amount of fix-up work is necessary, it should happen only once. Also, work on this scale and on a live article as important as this one should be carried non-destructive, that is, not delete stuff here before the infrastructure is ready and functional elsewhere. The fact, that you already made a number of mistakes while attempting to split out the contents, is what makes me sceptical if you are really aware of the complexity and careful enough to carry out this task properly, that's why I offered to do it myself if there would be consensus to do it (and when I have a large enough time slot for it). This should also help you to actually add the stuff you said you have in mind.

While I am still not yet convinced that it would be beneficial for the article and Wikipedia to split out anything at present, the size issue could be addressed by moving the technical chapter into an article of its own alone. I would suggest a title "Design of the FAT file system" rather than "File Allocation Table technical design" (and, just in case this would become necessary at a later stage, for the history stuff I would suggest a title "Evolution of the FAT file system" or "History of the FAT file system" rather than "File Allocation Table historical evolution"). Instead of moving the history bits elsewhere, we could create a new heading "Variants", grouped with the existing chapters "Extensions" and "Derivatives" under a new top heading "File system types", leaving the remainder of the "Historical evolution" chapter intact. "Variants" would then get more abstract and functional descriptions of the various core file system types in new chapters "FAT12", "FAT16", "FAT32". Like this:

• Intro
• Overview

• Nomenclature
• Concepts
• Uses
• Fragmentation
• Legal matters

• Historical evolution

• Original 8-bit FAT
• FAT12
• Initial FAT16
• Logical sectored FAT
• Final FAT16
• FAT32

• File system types

Hatnote: Main article: Design of the FAT file system

• Variants

• FAT12
• FAT16
• FAT32

• Extensions

• Extended Attributes
• Long file names
• Forks and Alternate Data Streams
• UMSDOS permissions and filenames

• Derivatives

• Turbo FAT
• FATX
• exFAT

• See also
• Notes
• References
• External links

Since you haven't been specific so far, I can only imagine what you have in mind for the article, but it seems, the anticipated additions might fit in nicely under "Concepts" and "Variants". And once those new "FAT12", "FAT16", "FAT32" chapters are rounded out, we may reconsider to split out the history stuff into an article of its own, and it would no longer make this article a shell without contents at the same time.

--Matthiaspaul (talk) 13:45, 20 May 2014 (UTC)

Glad the technical details were split out; thanks Matthiaspaul and KvnG! — JFG ^talk 08:31, 12 June 2014 (UTC)

Boot sector jump code 0x69

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. 79.152.196.39 (talk) 17:29, 30 August 2013 (UTC)

Your observation is (mostly) correct; 69h is no officially supported opcode for any kind of jump, return, call, interrupt or halt instruction on any x86 processor I am aware of. Actually, it is used to encode IMUL since the 80186/80188, and an IMUL neither fits into the three bytes reserved for the jump etc. nor does it make sense as the first instruction executed in a boot sector.

Nevertheless, the description in the article's boot sector section is correct. MS-DOS, PC DOS and DR-DOS do in fact check for this strange opcode sequence (69h xxh xxh) when trying to log in removable media (that is floppies and superfloppies). I know from personal experience that this is true, but if you do not believe me or the references given, you can easily verify this yourself using a debugger or disassembler, or you could check out how DOS reacts when you change the values in these locations using a disk editor.

The question remains, what is the purpose of this code sequence? Unfortunately, while I have several ideas, I cannot answer this question with certainty (in fact, this is one of the very few remaining open questions in regard to the history and inner workings of the FAT filesystem).

• It is possible that 69h is an undocumented opcode on 8086/8088 processors (possibly only in certain steppings) either by design or due to incomplete opcode decoding (in the later case, 69h might do the same as E9h). What about x86 clones like the NEC V20/V30 (perhaps in 8080 emulation mode) or the K1810BM86?
• It is also possible that it is a jump etc. in some non-x86 CPU. Microsoft once had an operating system named MSX-DOS, which did support FAT12 and ran on 8080/Z80 CPUs. There were 8080/8086 dual-processor variants of Digital Research's Concurrent DOS 8-16. There even was a version of Concurrent DOS 68K for Motorola 68000 CPUs, supporting FAT. GEMDOS on the Atari ST series supported FAT12 and FAT16 as well. IBM had a PC/RT machine using a ROMP processor. Early versions of Microsoft's Windows NT supported other non-x86 platforms as well... - I might have overlooked something, but for those non-x86 operating systems which supported FAT in the DOS timeframe important enough to warrant special cases to be implemented into DOS' own implementation, I could not identify any CPU family, where 69h would be an opcode making sense as a first byte in a boot sector.
• If it is not an opcode, it could be an artefact of some data encryption or copy protection scheme. Was there any software (disk tools? computer viruses?), which would change the first byte into 69h to "corrupt" a volume (stripping off bit 7)? Or were such corrupted data floppies mass produced by some vendor (close enough to Microsoft or IBM) by accident and then "rescued" by implementing a special case in DOS to make them usable without reformatting in order to save costs?
• Or is this some kind of special case for 86-DOS or DOS 1.x media, when boot sectors did not contain a BPB? (At least not so on my share of floppies from this era, PC DOS 1.0 and 1.1 disks did not have a BPB, but they already had a valid jump instruction in this location.) While the code is present in all "modern" versions of DOS, I haven't checked DOS versions prior to 3.3 yet - seeing when this was added (if it wasn't included right from when BPBs where introduced with DOS 2.0), might help to find the answer.

Of the three references given, two (the DR-DOS MRS kit and Geoff's book on DOS internals) can be used to verify the accuracy of the statement. The third reference (Microsoft MS-DOS Operating System Programmer's Reference Manual for DOS 3.1) does not directly support the statement, but it contains the following odd and confused description in regard to the jump instruction at the start of a boot sector:

"Determine if the first byte of the boot sector is an E9H or EBIT (the first byte of a 3-byte NEAR or 2-byte short jump) or an EBH (the first byte of a 2-byte jump followed by a NOP). If so, a BPB is located beginning at offset 3."

I included this reference in the remote hope that this strange description might help to shed some light at the issue as well - after all, what did they mean by "EBIT"? Or was this just another of the many errors in this Microsoft publication?

Any ideas on the origin or purpose of the 69h as the first byte in FAT12 (or FAT16) boot sectors on floppies or other removable media are highly welcome.

--Matthiaspaul (talk) 11:36, 31 August 2013 (UTC)

I do believe that DRDOS checks for 0x69 (I just don't understand the reason, like you) and what I don't like to read in the article is the word "jump" together with 0x69 as I don't consider probable it to be a jump. "opcode 0x69" or "0x69 byte" would be more exact.

My mistake: IMUL is not a 386 instruction. It is available since the 8018x, as you said.

About the possibilities you have found:

• NEC instruction: NECs included all 8018x instructions. To NEC naming, 0x69 was MUL, but NEC didn't use the same names than Intel, and NEC's MUL was the equivalent to Intel's IMUL (Intel's MUL was NEC's MULU). And in emulation mode 0x69 is a valid 8080 opcode (see next paragraph).
• Non-x86 CPU, but on a system using FAT (when?): For the 68000 (Atari ST) 0x69 is the opcode for a conditional jump, I think BVS (branch if overflow). Takes 2 or 4 bytes. A bit strange something conditional here. Also, if it didn't jump, the code would execute the next 2 bytes... For the 8080 it was a MOV L,C and for the Z80 the equivalent LD L,C. Takes 1 byte. Well, I don't know what next bytes were, but such instruction doesn't look like a good pattern to search for, because L and C are general-purpose registers. I mean: You can say "it's a jump" if the opcodes are 0xE9 or 0xEB, but you can't reach any conclussion if the opcode means MOV L,C. No idea about the ROMP processor. And for NT for other architectures, it would be nice to know when DRDOS started doing this test. Anyway, I think all "other architectures" were pure 32-bit machines, with any instructions taking 4 bytes, but I'm not 100% sure about this.
• Not an opcode: For me it's the most probable. More than an invalid or undocumented 8088 opcode. What about changing a single bit from 0xE9 so that, for some reason, DRDOS first hid a volume to Microsoft software? (and then, next version of MSDOS also started to do the same check) -- you wanted new ideas :) BTW, I have a working 8086 and can do the test.
• About 86-DOS, DOS 1.x: In 86-DOS the CPU was also a 808x, and as you say, DOS 1.x has a "normal" jump instruction (even if it wasn't needed as there was no BPB nor OEM string in the boot sector).

And about "E9H or EBIT": It's just a possibility, but a white mark on the "H" in EBH could make it look "IT" instead of "H". If the original document (hand-written or typed) with the original white mark on EBH was passed to a non-expert, he/she could have converted it to "EBIT" in the final printed version. At least some OCR's would do it...

--Raul 88.11.136.110 (talk) 19:24, 2 September 2013 (UTC)

Thanks for your reply. You come to similar conclusions as I.

Well, even when assuming that "EBIT" is down to some transmission error (I have the actual book in front of me, it's really written as "EBIT" in there), the description still does not make much sense. To me, it appears as if they wanted to list three magic values rather than only two, but somehow screwed up doing so, possibly due to incompetence on the editor's part (I included that reference to get more opinions on this)...

In the other book I gave as reference, Geoff wrote in a section about floppy disk mounting:

"The jump instruction at offset 00h must be either a JMP NEAR (opcode E9h) or JMP SHORT (opcode EBh), the latter requiring a NOP to make up the three bytes of the field; to support older formats the first byte may be 69h."

An equivalent section about hard disk mounting does not contain the 69h stuff. He does not mention a specific DOS version for the floppy mount section, but the book deals with all kinds of DOS versions including some non-IBM OEM versions of MS-DOS and it is mostly written from the MS-DOS/PC DOS 5/6 perspective.

In regard to DR-DOS, the relevant excerpt of the floppy login code looks like this (I can reproduce this here as the 7.01 source code was once published; the code has changed somewhat in newer versions, but the excerpt is still fine to illustrate the point):

        ...
	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:
        ...

Regarding your disk protection idea, I think, I can rule this out. DR-DOS in fact has an optional security component which would require a password to be entered before giving access to a volume, but it's significantly more sophisticated than just changing a single bit.

While I have mentioned some DRI systems above in order to open the scope when seaching for possibilities, I personally assume that the 69h case was first implemented in MS-DOS or PC DOS. Therefore, I had a conversation with one of the PC DOS developers at IBM. While he wasn't the author of that particular section and did not have sharp memories, he recalled vaguely that it once had been his assumption that this was implemented for backward compatibility with old DOS versions. However, his statement was way too vague to base anything on it.

Another possibility would be some odd MS-DOS OEM version; some of them had really interesting floppy formats. Unfortunately, 69h still would not make sense for those I have examined (but there were more).

I think we can rule out the NECs. But if you have a 8088 or 8086 up and running to perform some tests, great (as my old machines are stored away in the attic).

--Matthiaspaul (talk) 23:19, 2 September 2013 (UTC)

If the check for 69h is done just for floppies, it suggests (to me) that the affected boot sectors were produced only before DOS 2.0 (before FAT hard disk support).

My 8086 is not at home but I will test it some day this week. It has MS DOS 3.2 installed (maybe Amstrad OEM). Will be enough to make a 3.20 bootable disk, then change E9h for 69h, next try to execute DIR, and finally try to boot?

--Raul 217.71.18.36 (talk) 07:47, 3 September 2013 (UTC)

Yes, 69h is checked for only for floppies. And yes, if 69h is an undocumented alias to E9h on the 8086 and the code already exists in Amstrad MS-DOS 3.2, changing this byte is all that is needed. Alternatively, you could also run a few tests in DEBUG.

--Matthiaspaul (talk) 11:26, 3 September 2013 (UTC)

I must admit that I didn't have much faith on it... but it works! I created a boot disk with MS DOS 3.30 (it wasn't 3.20), checked boot sector and it started with EB 34 90. The equivalent E9 jump would be E9 33 00 (tested and booted OK). Then changed E9 for 69 and it still booted OK on my 8086.

I keep thinking that the best explanation for not allowing 69h in hard disks is that DOS 2.0 was released for the XT and XT/286, so it had to work on 286 (where 69h is IMUL). So all boot sectors with 69h were produced before DOS 2.0 (before any 286 PC, and before hard disk support). So, it's impossible to have a DOS formatted hard disk with 69h. So... no need to check for 69h on hard disk.

Any loose end left?

--Raul 88.18.36.31 (talk) 13:51, 5 September 2013 (UTC)

If I may. Is any result of this discussion supposed to end up in this article, already overloaded with technicalities? Because if yes, I will just say that original research is prohibited in articles. So if you want to include it, you need to have a reliable source for it. And if no, I shall remind you of the box at the very top at the page, saying that talk pages are not forums for general discussions of the article's subject; they are supposed to discuss eventual improvements to the article. Keφr 06:41, 6 September 2013 (UTC)

Kephir, this discussion is focussed on improving the accuracy of the article, so that we do not spread inaccurate or incomplete information. It is not forum talk and it is not about overloading the article with technical details. It is also not about original research. This is sourced by reliable sources and would not need further explanations as is. However, beyond knowing and just describing that something works in a particular way (as we do now), it is often helpful to understand the background, why it works and/or was implemented in a specific way and not in another. The fact, that we (I) do not know the answer to this specific question with certainty does not mean, that the answer is not known by someone else - actually, it is obvious, that there must be people who do know the answer to this very question, otherwise it would not have been implemented and maintained this way in various operating systems over decades. Also, the fact, that something is implemented in a specific way means, that there was a need to implement it this way. While the discussion above contains some speculation as part of the public brainstorming process, the goal is not to introduce speculation into the article (that's why my original description in the article deliberately remained vaguer than necessary in regard to this). Actually, the opposite is true, the discussion above can help to find answers and rule out certain possibilities and thereby reduce speculation. It will lead us to find even more sources as well as more accurate and comprehensible descriptions in the end. This ultimately helps to improve the article and fulfill Wikipedia's goal to become the highly reliable reference anyone can depend on - from laymen to experts.

--Matthiaspaul (talk) 09:45, 6 September 2013 (UTC)

Raul, to rule out other possibilities, what happens if you implant EBh FEh 90h instead (infinity loop -> to check, if the code is actually executed, not bypassed by the BIOS) or EBh 33h 90h (jump one instruction too short, running wild -> Does it recover? To see if the 00h in 69h 33h 00h is actually part of a 16-bit argument or not, assuming for a moment 69h were not an alias to E9h, but to 79h, a conditional jump with 8-bit signed displacement which could be coded as 79h 33h).

--Matthiaspaul (talk) 10:47, 6 September 2013 (UTC)

I can try, but as I agree with both of you and Kephir, can I send you the results another way than here?

--Raul 88.15.199.227 (talk) 16:58, 6 September 2013 (UTC)

Small update:

According to a thread "Undocumented 8086 Opcodes" http://www.os2museum.com/wp/undocumented-8086-opcodes/#comment-87135, started by Michal Necasek on 2013-12-21, the MS-DOS 3.21 OEM Adaptation Kit (OAK) describes the 69h opcode as "direct jump" (in contrast to E9h being a "DOS 2.0 jump" and EBh being a "short jump"). (I cannot personally confirm or deny this, but that thread cites a small excerpt of the MS-DOS source code indicating this.) Unfortunately, this still does not make much sense, but at least it can be deduced from that thread that the code was added with MS-DOS/PC DOS 3.20 (does not exist in 3.1) in 1985/1986, and it was removed in MS-DOS 7.10. And we have confirmation, that on a Siemens 8086-2 the 69h opcode functions as an undocumented alias to 79h (JNS). What is a bit pity is the fact, that although at least two of the participants over there are aware of the prior discussion(s) here (because they participated in them), they don't mention or link to them. --Matthiaspaul (talk) 04:14, 19 April 2015 (UTC)

Cut into two articles for FAT32 and FAT16

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)

Why? As a device driver developer who has written drivers for FAT12/16/32, they have a lot more in common than differences. —EncMstr (talk) 01:15, 20 November 2013 (UTC)

Default file system for media section

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

DVD-RAM and PD disks and MO disks, ...

Actually, "random access removable media" would be misleading, I know of at least one implementation utilizing the FAT file system on tape storage (by Hewlett-Packard). In fact, I still have one such drive in use. --Matthiaspaul (talk) 12:32, 4 May 2014 (UTC)

FAT vs NTFS, starting with compatibility issues

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)

There is no compatibility section because there is no compatibility to speak of. They are independent, separately implemented file systems. The only thing they have in common is that file names are case-insensitive and can contain the same set of characters (and sometimes not even that). Keφr 16:58, 6 March 2014 (UTC)

Besides, NTFS file systems are neither predecessors nor successors of FAT file systems. They are (at least for some time) parallel developments serving different needs and usecases and having considerably different requirements. Depending on circumstances, either of them can be the better choice. They are not compatible with each other at all. --Matthiaspaul (talk) 11:31, 4 May 2014 (UTC)

ZIP disks (Iomega)

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)

Zip disks are on the radar of almost no one. Besides, there are dozens to hundreds of ancient devices which used FAT for interchangeability. The VAX-750 comes to mind. I don't think that an archaeology section would add much value to this article but, if you want, maybe you could create a List of computer systems supporting the FAT filesystem (not a good title) and link to it from this article? —EncMstr (talk) 01:43, 13 March 2014 (UTC)

Actually, we do list a number of specific FAT geometries in the article, but only, when they are important in the historical context or when there is something special about them from a file system implementation's view, so that implementations can cope with whatever is special about them. This includes a number of hard-wired geometry profiles associated with certain FAT IDs on media without valid BPBs. The rationale for this is that these fall-back profiles are an integral part of the design of the FAT filesystem, and generic FAT implementations not taking them into account cannot be called 100% compatible.

However, from the viewpoint of a FAT driver there is nothing special about the FAT16B format used on ZIP-100 disks, because its boot sector contains a BPB with valid geometry entries for the file system driver to work with. Therefore we don't need to mention them in the article.

Nevertheless, the exact physical and logical geometry parameters of such media should be mentioned in the corresponding articles (similar to what we do for LS-120 and LS-240), as these parameters are important to know for developers of various disk maintenance tools, but not for implementors of file systems.

--Matthiaspaul (talk) 11:17, 4 May 2014 (UTC)

Article too long

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)

I think the best proposal for addressing this is described above in #What is this huge thing in the middle?. Please have a look and weigh in on it. ~KvnG 16:24, 20 March 2014 (UTC)

8-bit original FAT specification?

Where can I find the original 8-bit FAT specification? Benhut1 (talk) 23:33, 3 May 2014 (UTC)

Unfortunately, little is known about the 8-bit FAT variants implemented in Microsoft Stand-alone Disk BASIC-80, Stand-alone Disk BASIC-86 and MDOS/MIDAS between 1977 and 1980. While their main characteristics are already discussed in the article (sometimes only implicitly), various important details are still missing.

It was used on 8-inch and 5.25-inch floppy diskettes.

The disk layout was significantly different from that of FAT12 etc. The FAT area consisted of 3 FATs with 8-bit table elements. Reportedly, the number of FATs was a compile-time parameter for MIDAS already, but not for Stand-alone Disk BASIC, which always used 3 FATs. (It is a parameter typically set to 2 in FAT12 and later.)

There was no FAT ID at the start of the FAT (and no BPB in the reserved sectors area), so it was impossible for the operating system to detect different logical FAT formats. Instead, the parameters had to be provided when mounting a volume under Standalone Disk BASIC and MIDAS (whereas 86-DOS later used different drive letters associated with different logical geometry profiles).

Valid data cluster values were up to 0xBF. Accounts differ in regard to if 0x00 and 0x01 or 0xFF and 0xFE were reserved for special purposes. Either 0x00 or 0xFF defined unallocated areas.

Cluster values 0xC0 to 0xCD were used as end markers for FAT chains (similar to 0xFF8 to 0xFFF in FAT12), but in contrast to later FAT file systems they served another purpose as well: These values were also used to indicate the number of sectors (0 to 13) used up by a file in the last cluster of a file's cluster chain.

Standalone Disk BASIC used 16-byte directory entries whereas at some later stage MIDAS used 32-byte directory entries (but different from the 16-byte format used by 86-DOS before 0.42 and the 32-byte format used by FAT12 since 86-DOS 0.42). Filenames were 6.3 in Standalone Disk BASIC, unknown in MIDAS. Sub-directories were not supported. Date and time stamps were not supported as well.

Attributes were supported, but for considerably different purposes than known since FAT12. Some sources seem to indicate that file sizes were limited to 16 MB (theoretically) by a file's directory entry). File sizes could not be recorded with byte-granularity at all - only the number of allocated sectors (or clusters? - see special purpose of FAT chain end markers above) were recorded (similar to under CP/M).

If someone still has diskettes used under "NCR Disk BASIC", Standalone Disk BASIC-80, Standalone Disk BASIC-86, or MDOS/MIDAS, or could provide corresponding disk images, it should be easy to answer most of the remaining open questions in regard to these early 8-bit FAT variants using a disk editor or hex dump utility, but so far I haven't been able to obtain such disks. In 2012, Marc McDonald offered to provide original documentation and/or source code, but so far, I haven't seen any, unfortunately.

--Matthiaspaul (talk) 10:09, 4 May 2014 (UTC) (updated --Matthiaspaul (talk) 15:58, 11 May 2014 (UTC))

RFC on length and splits

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

I think my reverted edit clearly illustrates what I have in mind for the article. The recent work you've done on Design of the FAT file system is also work I proposed. ~KvnG 18:06, 21 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)

@JustBerry: can you elaborate as to why you think the current structure is acceptable? We no longer have any other editors that believe this is so. ~KvnG 17:12, 27 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)

There are different ideas floating around about how to name the split-out articles. I don't have a strong opinion about this and I think this can be handled as separate rename discussions. ~KvnG 17:12, 27 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)

That's reasonable and if I had any prior indication that this work was potentially controversial, I would have definitely considered this. The reason why I worded the RFC question as I did is that we have a significant amount of work on File Allocation Table historical evolution in limbo. If we leave that and work on the File Allocation Table technical design, it will be difficult to recover the work in limbo. Is there a good reason to let that go? ~KvnG 17:12, 27 May 2014 (UTC)

Good point. Can you and Matthiaspaul try to talk it out some more and at least clarify what you disagree on? I'm not sure exactly what you're at loggerheads about; are there still substantive issues of how much length and detail there should be, or is the main question as to who gets to do the annoying work of merging the edits? Rolf H Nelson (talk) 08:35, 28 May 2014 (UTC)

Rolf, actually, there continues to be disagreement about splitting out contents. I do not personally support the idea, because I think the information belongs into here. Nevertheless, I have proposed and mostly prepared the infrastructure for these two natural breaks years ago for the event that a split for technical reasons would become unavoidable at some point. While I do not agree that this time has come, I gave in to splitting out the "Technical Design" chapters to find a working compromise and move forward (I was actively and continue to be working on the article, anyway). So, the first part of your proposal is what already happened; I did it on 2014-05-20, that is, even before your comment - you seem to have missed that somehow (however, fixing up the many thousands of incoming links is still work in progress, except for the most important few hundreds ones).

This article discusses the various file system types in a serial structure (which happens to be mostly chronological arranged by nature), whereas the new technical Design of the FAT file system article naturally discusses them in parallel. While not as nice as in a single article, it is still a reasonably good solution.

With the size issue addressed, this RfC basically lacks grounds now, and we all could move on.

Unfortunately, Kvng does not seem to be out to find a compromise as well, when he now continues to propose splitting out basically all, that is left in the article. To illustrate his proposal, (per [2], repeated [3]) he wants all the following chapters:

2 Types

2.1 Original 8-bit FAT

2.2 FAT12

2.3 Initial FAT16

2.4 Logical sectored FAT

2.5 Final FAT16

2.6 FAT32

3 Extensions

3.1 Extended Attributes

3.2 Long file names

3.3 Forks and Alternate Data Streams

3.4 UMSDOS permissions and filenames

4 Derivatives

4.1 Turbo FAT

4.2 FATX

4.3 exFAT

to be replaced by the following sentences:

"The FAT file system was first implemented in the 1970s by Microsoft. Since then it has undergone significant evolution in support of increased storage capacity and functionality. Different variants and versions of the file system were introduced along the way. Different versions are not necessarily implemented by Microsoft nor are they necessarily compatible with one another."

All, that would be left is the "Overview" chapter, which I consider(ed) as kind of an introduction to absolute beginners. This article would be left with zero information useful for anyone actually interested in the FAT file system. It would make this article a shell without contents. It would be a total destruction of the article, on which other editors (including myself) have worked on for years.

Obviously, I fundamentally disagree with this (IMO absurd) proposal (and also with the suggested new title for the split out article, and also with the idea that Kvng would carry out any such split-out, given that, when he tried, it was technically carried out badly in multiple ways). I don't think there is any consensus for it (mind, that the discussions further above were still about addressing size issues and splitting out the detailed technical design part - issues already addressed now).

Kvng seems to be more after an hypothetical "Introduction to the FAT file system" (per Category:Introduction articles) than an article about File Allocation Table, a highly technical subject by nature. In fact, I encouraged him to write such an article, if he really thinks it would benefit the project, but instead he continues to focus on this article. His potential contributions may also fit in nicely in the "Concepts" chapters, but there's nothing to evaluate at this time.

In contrast to this, my proposal (as already suggested further above) is not to split out or delete information, but to expand the "Concepts" chapter to become an easy-language generic description of the file system, perhaps even include a few illustrations there. Now, that the "Technical Design" chapters have gone, there is various information that needs to be retrofitted. Information, which is specific to the particular file systems such as FAT12, FAT16, FAT32 etc. could be added to the existing chapters under "Types" (mind, that we have highly active redirects for FAT12, FAT16, FAT32 etc., which can only point to one place). Absolute beginners can stop reading after the "Overview" chapters without missing any information they don't need, but the "Types" chapters are already reasonably easy to read (in particular for a technical subject such as this one), although now, that we no longer have any article size issues to deal with, we could use a more elaborate language to make the existing information even more accessible.

Kvng did not really engage into the discussion of possible solutions further above, and has not given satisfactory answers to important questions raised above (like: What should be the new contents of this article then? Who should write it (given that in all those years he did not join in and contribute to the article)? Where should redirects like FAT12, FAT16, FAT32 point to, if, after a split out, there would be more than one place with information about these file systems?) Basically, he suggested to think about it later on. To me, this clearly shows that he (and some of the other commentors) haven't thought through the idea... However, this long established article is way too important and complex for careless trial-and-error editing IMO.

--Matthiaspaul (talk) 13:53, 28 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)

The discussion above 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.