Talk:File Allocation Table/Archive 5

Archive 1

←

Archive 3

Archive 4

Archive 5

Archive 6

Long file names on fat12, fat16 and fat32.

The "quick facts" box has the information on filename size split vertically to say 8.3 on the left, and 255 with LFN/vfat on the right (under fat32).

I would suggest to make the box split horizontally, so that "8.3" spans fat12 to fat32, and "255 with LFN/vfat" spans the same width. Floppies support LFN/Vfat just like natively fat32 only supports 8.3, and it still requires LFN/vfat support for longer filenames. (the combination fat32 / no-vfat of course is very uncommon: vfat is much older, and very convenient, so noone in their right mind would leave it out.)

In scanning this discussion page, I saw something about filesystem sizes, and what the max would be, and confusing operating support for formatting such partitions with fat filesystems. The facts are: Clusters can be a maxiumum of 32kbytes. fat12, fat16 and fat32 have 12, 16 and 28 bits respectively for the cluster number. This leads to 2^n-16 max clusters (the article mentions "19" as the constant. Doesn't make a significant difference). This gives 127.5 Mb max for a fat12, 2047.5 Mb (2Gb) max for fat16, and 8Tb max for fat32. WD delivers external 500Gb drives preformatted with fat32. I formatted a 500Gb external drive this morning with fat32 using the "mkdosfs -F32" command under Linux. 83.117.26.61 (talk) 13:05, 24 August 2008 (UTC) Roger Wolff august 24, 2008.

Yeah, the information about long file names was wrong. It used to be right, but it was broken by this "minor" edit six months ago, and you seem to be the first one to notice. I fixed it. The information in your last paragraph is correct except that (a) many FAT implementations support 64K clusters (NT does, I think win9x may, and my Canon digital camera with a proprietary operating system does) and (b) I think FAT32 is also limited to 2³² sectors, which is just 2 TiB for hard drives with 512-byte sectors. -- BenRG (talk) 16:05, 24 August 2008 (UTC)

According to my windows 98 resource kit 98 kinda supports 64K cluster fat16 filesystems in that it can read and write them but none of it's disk utilities can work on them. I dunno what the situation is with other 9x versions of windows. Plugwash (talk) 23:48, 23 October 2008 (UTC)

remove "(ex-tended version)" from the table at the top of the page

The extra column makes the table so wide that it creates display problems for some browser setups, and a lot of information about it simply seems to be unknown. From what is written in the article, it seems dubious whether it's a direct continuation of FAT anyway... AnonMoos (talk) 12:34, 3 October 2008 (UTC)

I agree, and I went ahead and removed it. -- BenRG (talk) 12:52, 4 October 2008 (UTC)

Boot Sector Virus

There does not appear to be a Wiki article on Boot Sector Virus and there is no mention of it here. Certainly a search for "Boot Sector Virus" yields no relevant results.

I suggest (propose) that part of this page (on perhaps a new page linked to this page) be created to address this issue as well as identifying alternate means of scanning for and removing boot sector viruses. Enquire (talk) 13:37, 23 October 2008 (UTC)

TFAT not covered in ExFAT section

It appears ExFAT has a variant known as TFAT.

http://msdn.microsoft.com/en-us/library/aa915463.aspx

There is very brief wikipedia entry at http://en.wikipedia.org/wiki/Transaction-Safe_FAT_File_System

It would be nice to have a line or two here, a pointer to the other article, and may be some work on the other article if anyone is up for it. Gregfreemyer (talk) 22:20, 25 November 2008 (UTC)Greg Freemyer

I agree with your suggestion so I implemented it on this page. Please review and update as you feel necessary. Frankk74 (talk) 05:28, 14 October 2009 (UTC)

article needs improvement in references and such

The comment that NTFS is better performing and more efficient doesn't make much sense and isn't linked to references. I've noticed large sections of the article go without references while having such comments inter-spaced. where do we get that NTFS is faster than FAT? Reboot (talk) 20:30, 19 February 2009 (UTC)

It comes from accumulated actual experiences. See this, this, and this. Being simple doesn't mean it performs better. Consider the problem of reading all the clusters of a 4 GiB file: a FAT driver has to follow the FAT chain. If the file is unfragmented, it has to read every sector of the FAT containing chain data, plus the data. On the other hand, a unfragmented NTFS file, it has to read only the MFT entry which contains a "data attribute" which says X clusters beginning at cluster number Y. The driver is done reading the file placement information: only data accesses are needed. Likewise, looking up—and creating—files in the directory are faster on NTFS because of its B-tree directory algorithm. Much faster, especially with more files. —EncMstr (talk) 23:19, 19 February 2009 (UTC)

Accumulated actual experiences when not referenced to that claim is called WP:Original_Research. I am familiar with both the internal structures of FAT and NTFS, but my personal experience is not relevant. Of course on a fragmented FAT filesystem is slow depending on the level and of course reading the FAT table can be low performing, but so can reading NTFS's Access Control Lists. Neither of the above potential references are benchmarks and so the statement in the article is WP:Original Research, unreferenced and possibly false (which I noted). I agree that FAT is not a modern filesystem suitable for storing large files, though only support that being included in the article if there is a referenced authoritative source to go with it. Reboot (talk) 18:31, 22 February 2009 (UTC)

It's easy to come up with situations where FAT is faster than NTFS (and vice versa). I don't think we should be making blanket performance claims in the article. I removed what I think was the one under dispute. EncMstr, your second reference is full of factual errors—I'm mentioning this mainly to warn anyone reading this thread not to copy any of the numbers from that chart into our article (it's happened before). The other references don't seem very trustworthy either. -- BenRG (talk) 14:21, 26 February 2009 (UTC)

Opening Sentence

File Allocation Table or FAT is a computer file system architecture originally purchased by Bill Gates...

How can it have been "originally" purchased by Bill Gates? From whom did he purchase it? Who wrote it? This seems to be a very strange way to start an article. This smells as if it used to say "originally written" and was then altered by an editor who disagreed, with no real regard for the sense of what remained. For a relatively high-profile article, I would have expected better. 62.49.27.35 (talk) 16:29, 20 February 2009 (UTC)

I concur with the above. There seems to be much confusion between this article's information on development/ownership and the 86-DOS page. Could someone make a summery judgement? As far as I know, FAT was developed by SCP and based on the filesystem that CP/M used; that's why the 1.0 version had no subdirectory support, as directories didn't exist in CP/M.

65.24.246.184 (talk) 12:30, 26 February 2009 (UTC)

Extended Partition and logical drives

"so DOS was only prepared to handle one FAT partition. It was not possible to create multiple DOS partitions using DOS tools, and third party tools would warn that such a scheme would not be compatible with DOS. Simply allowing several identical-looking DOS partitions could lead to naming problems: should C: be the first FAT partition on disk, for simplicity, or rather the partition marked as active in the partition table, so that several DOS versions can co-exist? And which partition should be C: if the system was booted from a diskette?"

Which version of DOS was only prepared to handle one FAT partition? DOS 2.x could handle multiple partitions formated as FAT, and did not have Extended Partions.

When did third party tools warn that such a scheme would not be compatible with DOS? 40MB drives were available for DOS2.x, and were compatible with DOS, so any such warning would have been wrong.

When was there ever any ambiguity about the first partition being C: if the system was booted from diskette? DOS 2.x had a well defined drive lettering sequence.

- DOS allowed you to install block devices, ie file systems, in system.ini (normal .sys device drivers are not block devices). This was normally used in DOS 2.11 to support 40MB disks. You installed the other partitions as non-dos partitions, using something other than Fdisk. The installable device driver accessed the other partitions and made them available to DOS. The other partitions were normally (always?) formated using DOS format as FAT drives, so the partitions needed to be small enough to work with FAT.

I understand the ambiguity in saying that DOS supported non-DOS devices, but it's simple: DOS could not boot from a non-DOS device.

I understand the ambiguity in saying that DOS was only prepared to handle one FAT partition, and that needs to be fixed.

Later MS, Disk manufactures, and compressed-disk-utility suppliers worked out ways to make DOS boot from non-DOS disks. These boot schemes were not 'compatible' with DOS: DOS couldn't use the disk (or boot from the disk) unless you used a propriatary scheme to load a disk driver.

From the first IBM insisted that MS have a way of loading device drivers. System.ini is as much a part of PC DOS and MS DOS as Command.com, and all those early computers came with MS/IBM/Hitachi/whatever documentation on how to write DOS device drivers to support arbitrary hardware. On DOS 2.x this supported single disks up to 4 partitions (limitation of MBR format) each of 15 MB (limitation of FAT format), and multiple disks if you had the hardware to handle it. —Preceding unsigned comment added by 218.214.18.240 (talk) 10:57, 28 February 2009 (UTC)

system.ini ? Don't you mean config.sys ? 80.176.88.36 (talk) 15:54, 10 June 2009 (UTC)

---

Is this section topical? FAT is a file system, not a disk partitioning system. It is troubles of DOS that there was no clear distinction; the FAT system does not depend on DOS at all and used by many other systems like Windows NT, Linux, OS/2, as by some embedded systems like photo cameras. On other hand, you may create Linux and NTFS partitions on a so named DOS extended partition (0x05). It is the article extended boot record where we should explain partition records format, and the article DOS where we should describe its use under DOS. Incnis Mrsi (talk) 22:26, 14 March 2010 (UTC)

Anyone know which Windows OS(es) were the first to use journaling? (and what type?)

This article notes whether exFAT had journaling, but not FAT32 which was much more popular, and importantly, still in common usage on USB flash drives. —Preceding unsigned comment added by 24.155.22.160 (talk) 14:25, 10 March 2009 (UTC)

This isn't the place for such questions, try the WP:RD/C in future. But to answer your question AFAIK NTFS was the first journalling file system supported in Windows which has of course been available in every version of Windows NT since the first including the home user oriented versions (XP, Vista, 7) Nil Einne (talk) 09:20, 18 September 2009 (UTC)

A couple of queries on the patents

1. when do they expire?
2. are there any known counterpart patents in other countries?

-- Plugwash (talk) 02:12, 31 March 2009 (UTC)

Other statistics

Minimums

Other interesting and useful statistics can be cited from Limitations of FAT32 File System (MS-kb:Q184006) —DIV (60.241.29.241 (talk) 14:58, 15 April 2009 (UTC))

binary accounting terminology

In the introductory table pseudo-SI prefixes are used: TB, etc.. Later in the article, more care has been taken to specify capacities using binary multiples: GiB, etc.. I recommend that as this article deals inherently with disk capacities, the more precise/relevant terminology should be used throughout. Generally this will mean using GiB, TiB, etc.; however, if there is a statistic that really is 10⁹ bytes (say), then an exception can be made. —DIV (60.241.29.241 (talk) 15:14, 15 April 2009 (UTC))

ISO GiBberish is good for sales of GB as 1000*1000 KB; and ISO is (indirectly) dominated by manufacturers. The article consistently uses GB as 1024*1024 KB, and the manual of style agrees with this practice when talking about RAM or disk sizes. –89.204.153.138 (talk) 21:57, 23 July 2011 (UTC)

LFN

What about 4DOS LFNs? It's not like MS is the sole creator of them. 76.66.202.139 (talk) 08:43, 30 April 2009 (UTC)

"4DOS LFNs"? 4DOS is just a DOS command processor, a special kind of application (a very good one, though). 4DOS queries the underlaying DOS if the DOS 7.0 API extension for long filenames is present. If this happens to be the case (and LFN support has not been disabled in 4DOS.INI), the command processor will use this API. Otherwise it will use the traditional API for short filenames. That is, the actual support for long filenames is not implemented in the command processor itself, it just uses an optional interface, if present.

MS-DOS/PC DOS do not natively implement VFAT LFNs, that's why this API is not present in plain DOS before loading the Windows 4.xx GUI. However, if a plain DOS driver like LONGNAME, DOSLFN or LFNDOS implements LFNs in the filesystem (using the VFAT method or something else) and offers the corresponding API extension, 4DOS will be able to use long filenames under plain DOS as well. The same, however, also holds true for all other applications. There's nothing really special about it. DR-DOS COMMAND.COM, for example, also supports long filenames if the API is present.

Or did you mean the 4DOS/NDOS file description feature (DESCRIBE command etc.), which allows to store text strings (or binary data) in a hidden DESCRIPT.ION (formatted text) file residing in each sub-directory? While used for a different purpose, these file descriptions can, in fact, be seen as some kind of long filenames. Assuming someone would implement a driver offering the DOS 7.0 API extension for this, these 4DOS file descriptions could be used by unaltered applications in the same way as VFAT LFNs, of course.

--Matthiaspaul (talk) 14:20, 13 December 2011 (UTC)

There's also the Linux "UMS" file naming that pre-dates Win95 by a few years. 80.176.88.36 (talk) 15:52, 10 June 2009 (UTC)

32k clusters size untrue for FAT32

WinXP and Vista both support 128k and 256k clusters for sufficiently large sectors in their FORMAT commands. This article needs some cleanup on this point. 64.85.164.16 (talk) 21:41, 20 May 2009 (UTC)

thats probably [exFAT] which is different to fat. A cluster can't be more than 128 sectors of 512 bytes (64k)--58.111.132.76 (talk) 14:27, 31 July 2009 (UTC)

The information shown when you do FORMAT /? in Windows XP SP3 appears to indicate that 64.85.164.16 is correct. BrianDGregory (talk) 15:41, 18 November 2010 (UTC)

That information (128K, 256K for sector size > 512 bytes) obtained from the FORMAT /? command is for drives with sectors greater than (>) 512 bytes, an artifact of bygone days when 1,024-byte sector drives were available.

MidnightTwo (talk) 17:11, 17 June 2011 (UTC)

Windows 7 x64 and windows 2000 format also have these obscure cluster sizes, with everything virtual today I'll test it at some point in time. After all there is only one byte for the sectors per cluster, I'm curious how 512 or 256 are encoded in this byte. If that's what happens. And no, this is not limited to exFAT, windows 2000 doesn't support exFAT. –89.204.137.161 (talk) 02:10, 4 July 2011 (UTC)

My test with a VHD failed, but I finally understood the sector size detail. If the sector size is 1KB or 2KB instead of 512, then cluster size 128 = 0x80 still fits in a byte, and corresponds to /A:128K or /A:256K instead of /A:64K. For exFAT there are more /A options, presumably exFAT offers more than one byte for the cluster size. I added a line explaining /A:64K /A:128K /A:256K for sector sizes 512 1024 2048 at the end of size limits, please move it to a better place if necessary. –89.204.137.133 (talk) 21:26, 17 July 2011 (UTC)

Achtually, sector sizes larger than 512 bytes (up to 4 KB) are coming back into use again. Today, 512 bytes/sector is an artifact of INT 13h BIOS compatibility (not a bad one, but anyway). --Matthiaspaul (talk) 10:53, 17 September 2011 (UTC)

Sector calculation

Generally this article has been useful to me in writing a FAT driver on an embedded microcontroller, one observation. The article presently says:

"Clusters are numbered from a cluster offset as defined above. That is, a zero in 0x1a would mean the first data segment is at:

reservedSectors (noofFAT * sectors2FAT) (maxRootEntry * 32 / bytes2sector) − 2 * sectors2cluster"

Seeing as 0x1a is not usefully going to contain a zero, how about that be changed to:

Clusters are numbered from a cluster offset as defined above and the FilestartCluster is in 0x1a. This would mean the first data segment can be calculated :

FileStartSector = reservedSectors (noofFAT * sectors2FAT) (maxRootEntry * 32 / bytes2sector) ((FileStartCluster − 2) * sectors2cluster)

James Murray 80.176.88.36 (talk) 17:56, 7 June 2009 (UTC)

As nobody objected, I applied this change. With math tags I was getting a lex error, so I removed those tags. 80.176.88.36 (talk) 13:32, 25 June 2009 (UTC)

Is is just me, or on certain reloads of this article, does it change the wording so that every FAT is replaced with NTFS?

I orginally had an entirely different comment, but upon reloading the page, it corrected itself.

I've reloaded the page several times and it usually says FAT, but randomly it will come up NTFS and upon the next reload it reverts. Odd...

ShoaQua (talk) 16:57, 13 June 2009 (UTC)

Not that I've noticed 80.176.88.36 (talk) 13:32, 25 June 2009 (UTC)

Hi all, can FAT system use on SATA Hard Drive ?

I would like to use FAT32 System on SATA Hard drive. Is it possible to setup? If it is possible, please share to me clue. —Preceding unsigned comment added by 203.81.166.2 (talk) 09:47, 16 June 2009 (UTC)

Yes. The filesystem type is dependent on the operating system, not the drive hardware. After installing the drive, use your operating system's "format" or "prepare drive" command. If supported, one of the choices will be FAT32—or maybe just FAT. Give more specifics about your environment so we can be more helpful. —EncMstr (talk) 13:27, 16 June 2009 (UTC)

The interface itself shouldn't be an issue, however if you have a single partition filling a sata drive you almost certainly won't be able to format it as fat32 using the format tool in modern vernsions of windows due to it's size. Plugwash (talk) 09:26, 21 November 2011 (UTC)

removed JFAT reference

The article said that most other IBM PC operating systems "added support for VFAT, FAT32, JFAT shortly after the corresponding Windows versions were released." This JFAT had been added to the article in May 2007 and made an external link in September 2007. I thought JFAT might be some kind of journaled FAT, but the link was about a Java implementation of FAT, rather than a distinct on-disk format that other operating systems could want to support. So I removed this mention of JFAT (but not JNode) from the article. 85.23.32.64 (talk) 21:59, 7 August 2009 (UTC)

Date resolution

In the right hand side fact sheet, contradictary values under "Features":

• at Dates Recorded: ... (Accurancy to day only)...
• at Date Resolution: 2s

Which is it? Day accuracy, or 2 second accuracy? Jesselong (talk) 15:46, 7 December 2009 (UTC)

Each field has different precision. Not all time stamps are supported on all platforms. The modification/last write time which comes from before MSDOS 3 and was the only timestamp until rather recently, it is accurate to two seconds. Last access contains only the date. For the creation timestamp, it is accurate to 0.01 second. —EncMstr (talk) 19:38, 7 December 2009 (UTC)

FAT12 on non-floppy media

Windows 2000 and XP will automatically change media with a formatted size of exactly 32 meg or smaller to FAT12 when reformatting, even if the original media format is FAT16. There's no choice to choose between FAT12 and FAT16. I've tried to use command line switches to force small media to FAT16 and these versions of Windows won't allow it. If you have some older device that isn't compatible with FAT12 and cannot do its own media formatting, or can format but only if the card is "raw" unformatted or already FAT16, don't reformat your 32meg and smaller cards with Windows 2000 or XP. Windows 9x and Me only use FAT12 on floppy disks and will automatically change any non-floppy media that's FAT12 to FAT16 when reformatting.

The flipside is that XP's default choice for non-floppy, non-hard drive media 64 meg and up is FAT32 but the user is allowed to select "FAT", which in that case means FAT16, unless the volume is over 4 gig. —Preceding unsigned comment added by Bizzybody (talk • contribs) 07:11, 23 January 2010 (UTC)

If this is right (somebody please confirm, or maybe I can check, to some extent anyway, later) shouldn't we move it to the main FAT page? BrianDGregory (talk) 23:33, 6 March 2010 (UTC)

Which flavor (12, 16 or 32 bits) of FAT file system is defined by the number of clusters so that, there cannot be a FAT16 system with fewer than 4085 clusters. Such a file system would be recognized as an invalid FAT12 system by Microsoft OSes and tools (that's explained in Microsoft's FAT specification). Consequently, a FAT16 system cannot be smaller than 2 MiB with 512 bytes clusters and a FAT32 system must be at least 32 MiB. Moreover Windows 9x format.com always try to create the smallest FAT flavor (i.e. FAT12 if it can), making clusters as large as needed, and so, format <32MB partitions to FAT12. This is independent of the drive type (floppy or hard drive). Linux's mkdosfs can create very small FAT16 systems (e.g. 3 MB) if the cluster size is specified on the command line.

exFAT aka FAT64. FAT64?!?

Shouldn't it be pointed out that exFAT is most definitely not a FAT64 and it is not sensible in any way to incorrectly call it FAT64 because FAT64 would be a FAT file-system where the FAT has 64bit entries. Please go to Talk:exFAT to discuss. BrianDGregory (talk) 23:26, 6 March 2010 (UTC) Now done. BrianDGregory (talk) 01:45, 15 March 2010 (UTC)

Directory Table and File Start Cluster

This section of the article needs to be clarified. The table calls it the "first cluster" and the paragraph after explains that "Clusters are numbered from a cluster offset as defined above." The table should mention that this is an offset. But what is this offset? It is never "defined above" as far as I can tell.

I was hoping the formulas answered that question, but they just convert from the number in the table to sectors from the beginning. Judging by the formula, it appears as though the offset is always 2 clusters before the end of the Root Directory. Is that the case? Why?

I'll fix the clarity on what I understand, but I can't say why the offset is what it is. Thanks. Slim (talk) 20:55, 24 May 2010 (UTC)

Ah, I see now. The first cluster after the root directory is number 2, and that will correspond to the the first available entry in the File Allocation Table. I'm going see if I can make that more clear. Slim (talk) 15:22, 1 June 2010 (UTC)

Is that question still unclear? The first data cluster gets number 2, because number 0 marks free clusters (or is a pointer to the parent directory, if that is the FAT12/16 root directory), and number 1 is reserved.

This corresponds to the two reserved entries at the begin of the FAT: 1 media ID byte followed by 2*nn/8-1 hex. FF bytes for a total of 2*nn/8 bytes = 2*nn bits, where nn is 12/16/32.

For nn=12 the purpose of number 1 could have been that the first data cluster entry should begin at a byte boundary (bit 2*12=24 results in the 3rd byte), and nn=16 or 32 inherited this oddity (wild guess). –82.113.99.129 (talk) 15:35, 14 July 2011 (UTC)

I've now expanded footnote name="two" into a reference name="two", stating the "count starts at 2" business. It does not exactly explain it, but clearly the media descriptor byte occupies a byte, therefore the count cannot start at 0. My best guess is that for FAT12 the first entry should start at a byte boundary, and that FAT16/32 inherited this FAT12 oddity. In a bold edit I noted that as a fact, please tag it with {{fact}} if you think that there might be more behind it. –89.204.153.224 (talk) 10:08, 19 July 2011 (UTC)

exFAT merger proposal

See Talk:exFAT#Merger proposal for discussion of a proposed merger of the exFAT article into the File Allocation Table#exFAT section of this article. Please add any comments to the exFAT talk page. — Richardguk (talk) 23:57, 8 June 2010 (UTC)

That idea was retired two days later, and in fact exFAT gets partition ID 07 (same ID as for NTFS), and might be nearer to NTFS than to FAT12/16/32. Not really any "FAT64", a (hypothetical) new version of FAT32 allowing 32 instead of 28bit cluster numbers with a 64bit number of total sectors (NTFS supports this) could be nicknamed "FAT64". –82.113.99.129 (talk) 16:37, 14 July 2011 (UTC)

Ignore the nonsense above (yeah, it was me), because it's exactly what exFAT does: 32bits cluster numbers, 64bits total sectors. Only the "FAT" on exFAT is not really a FAT, i.e., it's not used for sequentially allocated (= unfragmented) cluster chains. –89.204.152.53 (talk) 07:56, 19 October 2011 (UTC)

performance is poor

Removed meaningless/bogus "Performance is poor on many systems" c;aim from the introduction. Performance is excelent on many systems: in particular, performance is excelent on the many systems on which FAT was and is used. Not so good on systems with 1TB hard disks, which is a reason not to use it on such systems, but much better than NTFS on floppies and memory cards, and was widely used under Windows XP for video processing partitions, because a large FAT partition was so much faster than an NTFS partition. 218.214.18.240 (talk) 22:47, 17 September 2010 (UTC)