From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Software (Rated C-class, Low-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Low  This article has been rated as Low-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Software (marked as Low-importance).
WikiProject Microsoft Windows / Computing  (Rated C-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Microsoft Windows, a collaborative effort to improve the coverage of Microsoft Windows on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computing (marked as Low-importance).

Patent details[edit]

There are numerous patents describes in the article. It would be nice if someone knowledgeable about patents could explain the reach of these US patents internationally and when they will expire, in the US and abroad.

--Hans Deragon 2014-12-13 09:38:28 EDT

Support in Linux[edit]

Please work with this: (my english is not to storng for this job) Thanks! 27 Aug 2009

We need to say that Microsoft company didn't released exfat file system spcecifications. And i think Linux support is very experimental and it's not good to use for every day. —Preceding unsigned comment added by Kesrut (talkcontribs) 11:04, 16 June 2009 (UTC)

Agreed, and done. BabelStone (talk) 11:38, 16 June 2009 (UTC)

Added a sentence to the end of the appropriate part of the restrictive patents section referencing the current working FUSE based extfs driver for Linux. I know my addition needs work, was wondering if someone more knowledgeable about this driver might shed some light as to how complete it is as data is scarce. I know it's good enough to be in Ubuntu's main repository. Insidious611 (talk) 18:43, 29 September 2014 (UTC)

How max cluster size may be greather than max file size?[edit]

--Dojarca 14:25, 9 October 2007 (UTC)

Why not? It's not a contradiction. They may very well have designed it that way. Unsound (talk) 04:59, 7 June 2008 (UTC)

No idea, yet it hasn't been updated in Microsoft's Connect site; so unless it's being beta tested inhouse; who knows.. Many beta tester's including myself think that it may be dead. :( —Preceding unsigned comment added by (talk) 21:29, 16 October 2007 (UTC)

2^255 cluster size, that's great :)[edit]

it has to be 2^25 i think, because 2^25=32MB

-- (talk) 12:18, 19 March 2008 (UTC)

I agree that it does look a little weird, but look here [1] and you'll see that they too say that theoretically the FAT64 file system supports cluster sizes of up to 2^255. I guess they simply felt that oversizing one particular field in a header in order to absolutely guarantee future-proofness is a minor waste of space (32 bytes is really nothing). I would guess that the cluster size field is simply 256 bits long. Unsound (talk) 04:57, 7 June 2008 (UTC)
And I think it's one byte long, but its value means the exponent of 2. So the value 5 would mean 25=32 bytes or perhaps sectors. This would easily explain why the theoretical limit is 2255--Azarien (talk) 10:13, 21 January 2009 (UTC)
Yes, the 8-bit exponent is documented in the Microsoft patent application now referenced on the main page. Richardguk (talk) 22:47, 4 August 2009 (UTC)

The sector size is one byte, and is a power of 2. The largest sector size, as per the current specification is 4096 (2^12). The standard sector size is 512 (2^9). So the value is usually 9. The cluster size is not specified, the largest cluster as per the specification is 32MB (2^25) The number of sectors per cluster is one byte, is a power of 2, and specifies the blocking factor. The two bytes (sector size and blocking factor) must be <=25. — Preceding unsigned comment added by Rshullic (talkcontribs) 18:07, 17 October 2012 (UTC)

Windows Server 2008[edit]

I added Win2008 to the initial description but couldn't find an external source...I know it supports it because I just formatted my flash drive with it :-) I suppose I can't use a screenshot of the format screen as a citation... —Preceding unsigned comment added by (talk) 14:29, 16 May 2008 (UTC)

I think there's no need for external sources for things that are easily verifiable by anyone.--Azarien (talk) 10:16, 21 January 2009 (UTC)
I can verify that. File system driver exists in Windows Server 2008 and there is support in the "format" utility. So it's fully usable. I added it to the info box. Unsound (talk) 04:47, 7 June 2008 (UTC)
I've just had a go at using an exFAT formatted drive with a Win2008 server and the server didn't want to copy files larger than 4 Gb to it. It may be a local phenomenon but a warning might be in order.

Merge with File Allocation Table?[edit]

All other FAT file systems are listed under the File allocation table article, and I don't think exFAT/FAT64 should be any different. Unsound (talk) 04:43, 7 June 2008 (UTC)

See #Merger proposal further down. — (talk) 17:16, 25 March 2013 (UTC)

Difference between "free space bitmap" and regular?[edit]

Isn't the standard "sectors used" map the same thing as a "free space" map? In one case you are looking at the filled portion of the map. In the other you are looking at the empty portion of the same map.

It's unclear in this article what function an entirely separate free space map provides compared to the regular sector usage map.

DMahalko (talk) 15:14, 16 March 2009 (UTC)

Support in Vista with SP2?[edit]

In the ReadyBoost page it says that Vista (with SP2) will be able to read exFAT. Yet this article says that it isn't able to be read in Vista. Is one wrong? Should this one be edited to reflect the information in the ReadyBoost page? -- (talk) 19:42, 12 April 2009 (UTC)

The ReadyBoost article now concurs with this page. BabelStone (talk) 11:38, 16 June 2009 (UTC)

Contradictory size limits[edit]

I've made several tidying updates to the main article, including new footnotes. But there seems to be a contradiction about the file and volume size limits between the specification appended to the patent application and the Knowledge Base article about the exFAT update for XP.

  • While implementation limits might reasonably vary, is it really theoretically possible for file sizes to reach 64 ZiB (276 bytes) when the internal DataLength field is a 64-bit byte count?
  • Does the 512 TiB recommended limit apply to all current implementations?

Richardguk (talk) 23:01, 4 August 2009 (UTC)

Further on the contradictory size limits, the Microsoft KB talks about theoretical vs. recommended sizes, and say the theoretical limit of FAT32 in Windows XP is 32GB. While this is the limit that XP will format to FAT32, it can still read larger FAT32 volumes made with other tools. I believe 2TB is the limit of FAT32, while 32GB is the recommended limit. —Preceding unsigned comment added by (talk) 16:02, 7 October 2009 (UTC)

If you read the KB on FAT32 for XP, it states that the maximum volume size of FAT32 is 8TB. What they did is take the maximum number of fat index (2^28) times 32KiB and that gives you 8TB. The idiot that wrote the KB did not consider that the BPB was a 32 bit number and FAT32 was restricted to 2^^32 sectors.

In exFAT, as I tried to explain, you have 2^^25 for the max cluster times 2^32 index = 2^57 bytes which is 128PiB. but it I really 2^32 minus 11, so its a little less. Now, to add injury, the current standard is LBA-48, which means you can only address with 48 bits. You can't get 64ZB until someone invents and implements LBA-64, and you still need to increase the size of cluster because the FAT is still 32 bits. So, in the XP KB they blundered the other way and took the 64 bit number in the BPB without looking at what the FS supports.

There is a blog from someone from MS that states when FAT32 development was being done, they did math (as we can see MS can't even do arithmetic) and figured that with a 32K cluster (this ws before 64K clusters were allowed) and a 32GB disk, there would be 1 million FAT entries, and 4 bytes per entry, that is 4mb of FAT. In a heavily allocated disk looking for a free cluster would mean reading 4mb of FAT to find it. FAT doesn't have B-Trees link NTFS, so yes, MS limited FAT32 and created this limit based on projected performance (back with Windows 95 OSR2 which was what? 1999) where I/O was slow.

They I look at it, you have theoretical limits (which in some cases is as relevant as the moon is made of cheese - a theory). Then you have the implementation, which Microsoft says this is realistic, or restricted due to other reasons, or MS puts a governor in to lock it there. An example of restriction could be something like the LBA-48 or something else. But I like to have a middle ground here, because there is theoretical and implementation, and in-between a "architectural" limitation. So, when you get to exFAT size, the maximum file size is Theoretical 16EIB because the length is 64 bits, the architectural length max is 128PIB (approx.) because the file system cannot grow that big, and the implementation is restricted to 512TB because MS limited the file system to that and a file can't be bigger than the FS.

This leaves us to cut through the noise and dothe mth nd show that there are contractions, why they are they, and what the numbers should be - we need to show out math — Preceding unsigned comment added by Rshullic (talkcontribs) 06:38, 1 June 2014 (UTC)

Invalid Patent[edit]

A section should be added which outlines the enormous amounts of prior art that exist that invalidates this patent. Either way NO PATENTED TECHNOLOGY should be ALLOWED to be made a STANDARD. This happened with GIFs and people are retarded to think this won't hurt them. —Preceding unsigned comment added by (talk) 13:41, 22 October 2009 (UTC)

That definitely doesn't warrant a whole section. And I'm not sure it warrants inclusion at all. This is a descriptive article, and while everyone loves to complain about software patents (in many cases for good reason), whining about it on Wikipedia in every case is petty, and not particularly encyclopedic. --ShadowRangerRIT (talk) 15:02, 22 October 2009 (UTC)
I agree. That is a criticism of the patent system (particularly as it exists in the United States), not of exFAT. It doesn't belong here. In any case, who is makign these assertions? It sounds like your view which we are not interested in as per NPOV. CrispMuncher (talk) 20:09, 22 October 2009 (UTC)
While largely agreeing with CrispMuncher and ShadowRangerRIT, the only thing I will point out is if there is specific reliably sourced criticism of the patents covering ExFAT, in particular allegations that some of the patents are invalid because of prior art, then there may be some merit to mention that in the article. However as I've mentioned this has to be specific and reliably sourced. General comments on how bad the patent system is or how the US or whatever patent office is always granting invalid patents because they fail to uncover prior art are not suitable for this article. And we also have to bear in mind WP:Undue Nil Einne (talk) 04:14, 25 January 2010 (UTC)
TRS-DOS 2.0 published by Radio Shack in 1978 may be prior art for at least two of the independent claims of US 2009/0164440 A1, and probably some of the dependent claims as well. See my blog entry [2]. --Brouhaha (talk) 06:03, 17 September 2012 (UTC)

Let me point out that US 2009/0164440 A1 is not the exFAT patent. The patent is one on extensible file system, which BTW was approved in 2013. And MS fought hard on that one because there was challenges. US 2009/0164440 A1 is wrongfully being called the exFAT patent because a copy of the specification was included as an appendix. US8583708 B2 (Nov 12, 2013) is the real exFAT patent.

In reading the article, including this section, we are seeing the same kind of gripe, which is all over the internet and I don't think is appropriate here. That is that the open source people are not Happy that a propriety file system is out there and people have to pay for it. They are also unhappy that Linux file systems such as ext2, ext3,and ext4 were not used instead. I just think that this type of complaining should not be here, and it needs to be removed. — Preceding unsigned comment added by Rshullic (talkcontribs) 06:47, 1 June 2014 (UTC)

Why not NTFS?[edit]

The article needs to discuss why Microsoft believes a new file system is necessary. Why not just use NTFS? Currently all the article says about this is, "exFAT can be used where the NTFS file system is not a feasible solution, due to data structure overhead," which is not at all clear. Comet Tuttle (talk) 01:00, 5 March 2010 (UTC)

It would need some sourcing to go along with it, but I suspect much of the "overhead" spoken of relates to permissions, security and ownership data which aren't really necessary on a portable storage medium. —Locke Coletc 02:10, 5 March 2010 (UTC)
I think Microsoft's statement is based on a marketing decision, not a technical one. System internals, originally by Mark Russinovich, posted a utility NTFSFlp at least eight years ago which modified the NT floppy driver to get out of the way and allow NTFS to format a floppy volume. It worked okay, but there were a few extra seconds of disk writing compared to a FAT file system that seemed lengthy, but really wasn't all that bad. The accompanying technical investigation reported that it seemed as though Microsoft sabotaged format by artificially increasing the minimum size of $LogFile. Naturally, Microsoft no longer offers the utility since they acquired System Internals.[3] The security overhead amounts to just a few clusters on a small NTFS volume. —EncMstr (talk) 06:24, 5 March 2010 (UTC)
One of the primary reasons is probably the amount of metadata NTFS stores makes it unattractive for smaller volume sizes. There's a knowledge base article on this: [4] which is old enough to consider it worth comparing to HPFS in addition. For a 100Mb partition metdata accounts for 4% of capacity. Reading between the lines and applying common sense it would be even more for smaller drives.
Also, NTFS is a much more complex standard. Embedded devices would need to be more powerful to deal with that overhead and sofrware development costs much higher. If you keep an eye on the embedded groups you'll see engineers having problems with plain old FAT. Targeting NTFS would be orders of magnitude more complex and also immediately rule out the small microcontrollers with a few kilobytes ROM and perhaps a kilobyte RAM. CrispMuncher (talk) 22:13, 5 March 2010 (UTC)

Thowing in my 2cents. First, look where exFAT came from. Windows CE, which is in the line of embedded systems. They are made to run with very small amounts of memory, low power, and the actual OS is minimized. Windows CE is like Windows, but a different code base. Windows XP embedded is desktop code, but stripped down and customized. (ok, I read about older Windows phones using NTFS for their OS). FAT was the logical choice to provide a lean OS with a smaller footprint, and as I read somewhere, to be able to put the code into firmware - this is the origins of exFAT. Second, look at where exFAT is going. It is considered optimized for flash memory. Today disks, even magnetic disk, but mainly large capacity flash storage AND SSD are leaving the factory pre-formatted as exFAT (and yes, some are still NTFS and even HFS or what ever MAC uses). But one of the major issues in flash is to limit the writes. in exFAT - the FAT is no longer used or updated - unless the FS is fragmented. The bitmap is used for allocation. reading a sector of 4096 BITS (512 bytes) give you allocation status on 4096 clusters, where when using a FAT for allocation, you would have to ready 128K because you needed to look at one 32bit word to determine if one cluster was allocated. This is also part of the performance improvement. And with the SDXC, reduction of limitations - breaking the 4gig barrier. Now, considering 4K TV resolution, recording HDTV is going to send bits like drinking like a firehose, besides the bigger bus (UHS-2) they need a lean filesystem where the overhead doesn't get into the way and slow things down

And one more thing (because I have been reading the SD specs), NTFS still has a largest cluster of 64K, exFAT is 32MiB, and the SD specification actually supports a maximum cluster (they call it an AU - Allocation Unit) of 64Mb. NTFS isn't cutting it. — Preceding unsigned comment added by Rshullic (talkcontribs) 07:02, 1 June 2014 (UTC)

exFAT aka FAT64. FAT64?!?[edit]

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. As far as I can see exFAT uses 32 bit FAT entries the same as FAT32. (exFAT may use 48 or 64 Bit FAT entries for really big drives -- I don't know because I haven't formatted anything really big as exFAT yet) BrianDGregory (talk) 23:04, 6 March 2010 (UTC) Now done BrianDGregory (talk) 01:15, 15 March 2010 (UTC)

I agree and finally removed the "FAT64" mentioning from the article. Even if some users seem to like coining new terms, we shouldn't condone this in Wikipedia. The filesystem discussed here is named exFAT. It does not (normally) have 64-bit FAT entries, so calling it FAT64 is wrong even in a technical sense. Also, the internal organization of the filesystem is significantly different from previous FAT filesystems such as FAT12, FAT16 and FAT32, so it really does not belong in this family of filesystems any more. --Matthiaspaul (talk) 04:51, 13 November 2011 (UTC)

This is not going to add anything, but I'll throw in my 2 cents. First - I AGREE, I so agree that I see FAT64 in many other places and it ticks me off. There is no place in ANY Microsoft document, presentation, or even KB that EVER used FAT64 term Based on the specification, the FAT is 32 bits, it doesn't change to 64 bits if the file gets bigger, there just isn't anything in the specification. And by the way, in FAT32, even though the FAT is 32 bits, it is really only 28 bits where the first 4 bits are not used. Maybe a result of the LAB-28 standard, don't know. A 64 bit FAT - even if planned, would be a big problem anyway, because the 64 bit file system size in the BPB would still restrict the total volume size to 64zb. — Preceding unsigned comment added by Rshullic (talkcontribs) 07:08, 1 June 2014 (UTC)

exFAT project[edit]

For a exFAT read/write implementation see . As far as I know they need testers and feedback! - 5 April 2010 — Preceding unsigned comment added by (talk)

Merger proposal[edit]

I propose that this page (ExFAT) should be merged with the File allocation table article for the following reasons:

-Virtually all formats relating to FAT (FAT, FAT16, FAT32, etc.) do not have separate articles - arguably these formats are more widespread and well-known than ExFAT

-This article's contents could be effectively placed into the File allocation table article; it contains no information that would need a separate article (e.g. history, development) - all it contains is general information about exFAT

--Michael Kourlastalkcontribs 20:05, 8 June 2010 (UTC)

  • Oppose: File Allocation Table is already a long article. exFAT is much shorter but more than a stub. If we merged exFAT into File Allocation Table#exFAT, some of the more detailed exFAT information could get lost or confused with the information applying only to earlier versions of FAT. In particular, I don't see how we could easily integrate {{Infobox filesystem}} infoboxes for both the legacy and the exFAT versions. It would also make it less clear which bits of the merged article were applicable only to legacy versions. Conversely, because the FAT12/FAT16/FAT32 versions are so much more widely implemented than exFAT, it seems likely that most readers of the main article will be uninterested in detailed information about the new version. — Richardguk (talk) 23:36, 8 June 2010 (UTC)

I oppose the merger, and agree this should be separate. — Preceding unsigned comment added by Rshullic (talkcontribs) 07:09, 1 June 2014 (UTC)

  • Oppose: despite its name, exFAT is not a simple variant of FAT in the way that FAT32 extends the pre-existing FAT file structure, but has a completely different structure compared with FAT12/FAT16/FAT32. It would be difficult to merge the two articles effectively and would be confusing to readers. BabelStone (talk) 00:26, 9 June 2010 (UTC)
  • Response from Michaelkourlas: Both of you in opposition make fair points that I had not thought of. I actually find myself agreeing with you in opposing the merger. Unless anyone has any objections, I will close the merger proposal by leaving exFAT its separate article. --Michael Kourlastalkcontribs 17:12, 10 June 2010 (UTC)

Suited especially for USB flash drives?[edit]

exFAT is a "file system suited especially for USB flash drives."

In what way is it suited especially for USB flash drives? Insterested (talk) 08:57, 13 July 2010 (UTC)

I guess exFAT has many of the useful/helpful features of NTFS but doesn't cause a lot of writes to the certain areas when files are read like NTFS which wears out flash memory. Also it doesn't have per user access restrictions which can be an annoyance with drives that need to be accessed from many computers. BrianDGregory (talk) 23:57, 31 July 2010 (UTC)
What kind of flash memory does not have load leveling? I think the question stands. Fnj2 (talk) 17:47, 19 February 2011 (UTC)
Any reference explaining why exFAT doesn't wear out pendrives faster than NTFS? — Preceding unsigned comment added by (talk) 20:08, 14 November 2011 (UTC)

I have already said a lot before )above). However, besides endurance, and performance that I specified already. It is important to align the file system to the physical structure of the flash memory, especially in SD cards, but any kind of Flash. For this reason there are separate alignments for the start of FAT and start of Cluster HEAP. If things don't line up, then it is possible that sectors don't line up properly with the page size and erase block size in the flash design. For example, in order to write flash memory, you don't just write, flash memory is like eproms, you have to erase the memory before you can write to it. And that memory is in blocks. If the filesystem doesn't align with these blocks, then by spanning a filesystem sector across two erase blocks means that to write the sector you need to erase, then rewrite two of those erase blocks, instead of one. real slow, and that is why you have wear leveling andhave to deal with the write cliff when they are properly aligned, it is worse when it is not aligned. — Preceding unsigned comment added by Rshullic (talkcontribs) 07:17, 1 June 2014 (UTC) and the OEM Parms in the VBR seems to be another flash friendly item because it allows flash parameters to be specified in the file system ----

New Apple Computers[edit]

The most recent Mac Mini [1] and iMac [2] both include SDXC card readers so presumably OSX should be added to the list of ExFAT supporting OSes? Urban worrier (talk) 18:22, 25 August 2010 (UTC)

This needs to be checked since these new computers might require you to re-format SDXC cards in some other format before using them. Or maybe they can only read exFAT and not write. Or maybe they are going to rely on you acquiring an exFAT implementation for OSX from somewhere else. —Preceding unsigned comment added by Briandgregory (talkcontribs) 14:53, 1 October 2010 (UTC) Sorry BrianDGregory (talk) 15:13, 1 October 2010 (UTC)

It seems confirmed that certain releases of MAC supports the exFAT, as id required for SDXC. Although I haven't tried it (but will soon) I heard that by using a camera adapter the iPAD can read SDXC. I don't know if it is true, or what IOS supports this, something to look at. — Preceding unsigned comment added by Rshullic (talkcontribs) 07:19, 1 June 2014 (UTC)

Add comparative speed differences: FAT > exFAT>> NTFS[edit]

I'm not an expert on filesystems, but when I used a USB flash drive for ReadyBoost, I found there were major differences in timings on machines and filesystems used. On my thinkpad laptop, writing to USB flash formatted NTFS was almost 6.5 times slower than if the same drive was formatted with FAT32. And I found that ExFAT is about 20% to 30% slower than FAT32! This seems very significant and should be mentioned in the article if someone can confirm this as well. Stk (talk) 04:44, 22 September 2010 (UTC)

NTFS is generally slow on low performance Flash storage. Yes for a drive used solely for ReadyBoost you obviously want the simplest crudest file system so it goes fast since you are clearly not worried about tracking access times or being able to recover data from the drive after a crash. BrianDGregory (talk) 15:43, 30 September 2010 (UTC)
Going somewhat off topic, if you want your Flash drives (and even hard drives) to go fast then try formatting them with larger allocation blocks. For flash drives in particular the Windows default size allocation blocks are usually much too small. When you get a new Flash drive it's always worth nothing down the original allocation block size before you reformat it and lose that information for ever. BrianDGregory (talk) 15:43, 30 September 2010 (UTC)

Partitions created OS X 10.6.5 are inaccessible from Windows 7[edit]

The article claims that partitions created OS X 10.6.5 are inaccessible from Windows 7 however I have not been able to find any confirmation of this either from Apple or Microsoft. Furthermore, in my own testing I have yet to experience any problems. --Severud (talk) 18:20, 13 December 2010 (UTC)

Opinion about the creation of exfat partitions in 10.6.5 removed by user mblwatson 11:44, 15 December 2010 (PST) because the article is not the place for such discussions. Should only be in the article if it is an issue recognized by Apple. — Preceding unsigned comment added by Mblwatson (talkcontribs)


Operating System Specifications[edit]

With the recent OSX update to 10.6.6, the exFAT formatting ability remains with Mac OSX. Should the specification be changed from "10.6.5" to "10.6.5+"? — Preceding unsigned comment added by Sire TRM (talkcontribs) 04:23, 7 January 2011 (UTC)


The link to the 1.0 specifications (in a patent application) is dead (at least for the purpose of providing the specifications). I don't seem to successfully tag it as dead, so I'm flagging the problem in this way.

Athulin (talk) 08:52, 23 January 2011 (UTC)

Devices capable to read exFAT[edit]

I can confirm the Sony BRAVIA EX-725 series is capable to read exFAT formatted drives connected on USB. -- (talk) 13:31, 8 April 2012 (UTC)

exFAT ships on all SDXC Cards, SD Card Association Link is broken. — Preceding unsigned comment added by (talk) 18:35, 24 April 2012 (UTC)

"As in FAT, when creating a file of known length, exFAT must perform a complete physical write equal to the size of the file."[edit]

I don't know about exFAT, but I'm certain that it is not true that "in FAT, when creating a file of known length [software] must perform a complete physical write equal to the size of the file." There might be an OS or driver limitation which would prevent file pre-allocation for some implementations, but there's no structural reason, inherent to the file system, that a file's space can't be pre-allocated on FAT12, FAT16, or FAT32 file systems. NCdave (talk) 17:05, 12 March 2013 (UTC)

I guess this is due to the security/reliability requirement that programs reading from allocated but not yet written clusters see only blank space (and not bits of deleted files). Without a way of marking a cluster 'dirty', only allocated or not, it's necessary to wipe the cluster itself. — (talk) 17:34, 25 March 2013 (UTC)
Regardless, the comment is just plain wrong. Admittedly I don't have access to an exFAT spec yet, but I'm very familiar with FAT and I can and do preallocate large files on FAT formatted sdcards in embedded devices. I don't care about the blocks not being zero filled. I suspect someone doesn't understand the distinction between a specification and one particular implementation of it. — Preceding unsigned comment added by (talk) 14:49, 17 September 2013 (UTC)

Let me point out one thing with exFAT that might bring some clarity. in the stream extensions record which has the length, there are TWO lengths. One is the actual file size, and the other is the length of the data that has so far been written into the file. This is called the Valid Data Length (VDL) feature and there is stuff in MSDN to use this feature to indicate how much data was actually written so far. ----


So there seems to be a substantial amount of comparison to FAT+ in this article. From the beginning of the article: ". . .where the file size limit of the standard FAT32 file system (that is, without FAT+ extension[7]) is unacceptable." Later, in the advantages section: "in a standard FAT32 filesystem.[2] (The open FAT+[7] specification proposes an extension how to store files up to 256 GB on otherwise backward-compatible FAT32 volumes as well. This extension is available in some versions of DR-DOS.)"

Is it just me or do these mentions smack of advertisement? They do not further clarify the subject of ExFAT, though they do serve to muddy up the waters a bit. I feel like, if FAT+ isn't worthy of its own page on Wikipedia, it shouldn't be hijacking the ExFAT page. Especially since it isn't even an official patch. — Preceding unsigned comment added by (talk) 13:38, 25 June 2013 (UTC)

I do think it is quite important to mention FAT32+ in the context of exFAT in order to maintain the neutral point of view and base comparisons on technical facts, not marketing and politics. There are two facts many of the less-technical readers are not aware of: FAT32 does not max out at 32 GB, but at 2 TB (or even at 16 TB with 4 KB sectors). The maximum file size of 4 GB on FAT32 can be easily expanded to 256 GB utilizing the open FAT32+ proposal. Therefore, for volumes smaller than 2 TB and files smaller than 256 GB, people would not have to switch to exFAT for technical reasons, whereas Microsoft (who owns and sells exFAT) documents the switch-over point at 32 GB and 4 GB, respectively. This is a very significant difference, technically (factor 64x actually), as it will still take many years before flash media (where FAT32 is used today and exFAT is targetted at) will have reached up into the 2 TB region, and when a need for (video?) files beyond 256 GB will become pressing. The point here is that with a very minor extension to the standard FAT32 format, people would not have to abandon the established FAT industry standard as a universal exchange medium now and switch to proprietary filesystems like exFAT.
exFAT does have a few advantages over FAT32, but they are irrelevant in many common use cases, where FAT(32) is used today as an exchange format on flash cards/sticks and where a relatively small number of large files is written once and not modified later on before the next delete/reformat (typically f.e. for usage in digital cameras, camcorders, and various kinds of media players). In these cases, exFAT does not offer any technical advantages over FAT32(+), but comes at the price of totally giving up compatibility with the long established standard. Therefore, I think, it is very important to compare exFAT with FAT32(+) in order to enable readers to make educated development and buying decisions.
FAT+ (or more precisely FAT32+ here) does not need its own page, because it is only a very minor extension of the standard FAT32 file system, which can be added to existing FAT32 implementations in a couple of hours, and as such it is already discussed in our File Allocation Table article (down to the technical details).
--Matthiaspaul (talk) 10:34, 1 July 2013 (UTC)

Article gives readers wrong impression, conflicts with related articles, needs significant rework[edit]

With the increasing popularity of Mac computers the issue of cross-platform data migration is common. I have seen people read this article, believe it's warning against using ExFAT, and make a suboptimal decision when transferring data.

This is caused by all the anti-ExFAT statements, some of which are not even correct. E.g, more lines in the article refer mention disadvantages than advantages. It reads as an anti-ExFAT article, not an unbiased, impartial encyclopedia. No other Wikipedia filesystem article does this: HFS, HPFS, NTFS, File Allocation Table, etc. Only this one.

E.g, this article prominently elaborates on the licensing status of ExFAT, which is not even relevant to most end users. By contrast the HFS article briefly mentions it's proprietary to Apple. The HFS article isn't used as a soapbox to slam Apple about HFS, which is correct since this is an encyclopedia, not an opinion piece in disguise.

Another example: article elaborates negatively on ExFAT having a single file allocation table, and implies this puts data at risk. In fact almost no system software uses the redundant file allocation tables on FAT32. The article makes a technical judgment without any corroborative basis.

I would re-write it myself but don't have time. I just wanted to mention these points to try and forestall some of the problems this article is causing. Joema (talk) 15:49, 7 August 2013 (UTC) joema

Regarding licensing & interoperability, this kind of critique is very much to be anticipated of an uninteroperable standard that gets adopted by industry. Get used to it. If you don't believe me, a good example is the critique against Adobe Flash (the industry standard), Silverlight (nobody cares) and HTML5 video (the interoperable). You are absolutely right that compatibility problems tend to be well hidden for most users. That's why I don't worry about those users — in my view, the most important thing with a standard is to not exclude anyone. I often feel excluded myself. (talk) 00:07, 10 February 2015 (UTC)

exFAT is now GPL2! :-D[edit]

After they leaked the code by accident, Samsung has released the sourcecode under GPLv2 license.

So it's free software.

--PabloCastellano (talk) 22:59, 26 August 2013 (UTC)

While this is very nice, it does not actually help the situation, unfortunately, as exFAT is owned by Microsoft, who has patented it. Even if Samsung's implementation is free, it cannot legally be used without a commercial license from Microsoft.
The problem with missing exFAT support in most operating systems isn't that the internals of exFAT are not known (even if Microsoft hasn't made them available to the public), but that it would be illegal to use exFAT without a license from Microsoft, even if the implementation is not derived from Microsoft's in any way.
So, unless Microsoft changes its mind and puts exFAT into the public domain or offers it under a GPL-compatible license, exFAT isn't the solution for a future compatible and platform-independent universal exchange format for media larger than 2 TB we are desperately looking for, as FAT12/FAT16/FAT32 was (and still is) for media smaller than 2 TB. --Matthiaspaul (talk) 23:33, 26 August 2013 (UTC)

ExFAT and TRIM[edit]

Does Microsoft's implementation of ExFAT support TRIM (discard) of un/de-allocated pages on the device? -- (talk) 18:34, 6 November 2013 (UTC)

Files not recognized by some devices with large exFAT-formatted USB flash drives[edit]

I removed the following recent addition by User:Gerixau from the article, but got reverted:

"Some media devices which support large USB flash drives do not recognise files on drives formatted with exFAT."

A vague and possibly confused assertion, IMHO, at least without any further explanations or RS.

Based on this description, the most likely scenario is that those media devices in question simply do not support exFAT. In contrast to SDXC and MemoryStick XC media, which mandate the usage of exFAT for media >32 GB per their specifications, there is no such requirement for other flash media such as CF cards or USB sticks. Therefore, even if a device supports media (other than XCs) larger than 32 GB in general, it cannot be assumed that exFAT is supported by the device, unless the device is explicitly specified to support exFAT, because exFAT is still relatively new, its specs are not open, there are only a few implementations in the field (and they are likely to be imcomplete), and offering support for it in a device (even when using a third-party inplemention) requires to pay license fees to Microsoft. Therefore, most users (and device manufacturers) simply use FAT32 instead of exFAT also for media larger than 32 GB, whenever they have a choice.

Another possible explanation for the user's observation are bugs in a specific exFAT implementation, which would not belong into the article as well, unless very prominent.

If these scenarios do not apply, the user needs to further elaborate on what he actually meant by his addition, and he must provide RS to back up the claims.

--Matthiaspaul (talk) 09:35, 9 May 2014 (UTC)

Flash Friendly Issues[edit]

The additional notes that was added to the two Boundary Alignment in my opinion need to be removed. Yes, I can do all kinds of padding and messing around with the file system to align the FAT and Cluster heap, but it is all a hack. exFAT provides a FAT Offset and a Heap Offset set of values to align those regions. Alignment comes under flash friendly because laying out these regions are made to conform with flash memory "page size" and "block erase size" which can affect both endurance and performance. For example, I was looking at how my SDXC card was formatted at the factory, and the FAT is 16K sectors into the filesystem, and the cluster heap is 16K sectors after that (at 32K). It is a SANDISK 64GB SDXC.

That is where the OEM Parameters come in. If you look at the layout of the OEM Parms, it has a GUID and then flash paramters such as page size and erase block size. The reference (since you want clarification) of what OEM parms is used for is at

These three items are considered improvements made by Microsoft, over legacy FAT (FAT12/16/32) to better support Flash Memory.

Before I go in and edit those remarks, I would like to give the community an opportunity to argue if they still disagree.

(I wasn't logged in, this is rshullic) — Preceding unsigned comment added by Rshullic (talkcontribs) 17:33, 4 June 2014 (UTC)

Number of Files per directory[edit]

I have trimmed this and moved it. FAT32 and exFAT do not have a limit for the root directory, the limit is for the sub-directory. For FAT16 & 32 (possibly 12 as well?) the subdirectory size is set by MS as a max of 2M, giving 64K directory records that are 32 bytes each. There is a reason for this setting, although it appears (and may be) somewhat artribuary. Unlike NTFS, there is no index, NTFS has Btrees to look stuff up. FAT (including exFAT) is brute force, you want to find a file, in a full directory of 256MiB, you have to search one by one. And there are 3x as many directory records, because to get to that number, it assumes 3 directory records per file, and you have to look at at least two for every file in there. It will take forever.

Just because other vendors violate the Microsoft spec and allow FAT32 directories above the specified limit should not make this a forum for Microsoft Bashing (I am NOT from Microsoft) because other people do it. That is what I see here, is a lot of subjective anti-Microsoft language because many of the open source people hate Microsoft and that was made a standard. I think we need to be professional, and stick with the standard. If other vendors are violating the standard, it may be reported, but the way people are going about it is like they are doing it in a way to rub it into Microsoft's nose.

And if this needs to go into a long why this or why that, it should go into a section with prose, not in this list which is meant to be a highlight bullet list.

I have also changed the title to try to get away from the pro/con format. — Preceding unsigned comment added by Rshullic (talkcontribs) 17:58, 4 June 2014 (UTC)