Talk:ExFAT

Support in Linux

Please work with this: http://lwn.net/Articles/348825/ (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 (talk • contribs) 11:04, 16 June 2009 (UTC)

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

How max cluster size may be greather than max file size?

--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 65.185.10.34 (talk) 21:29, 16 October 2007 (UTC)

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

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

--194.27.118.26 (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 2⁵=32 bytes or perhaps sectors. This would easily explain why the theoretical limit is 2²⁵⁵--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 (talk • contribs) 18:07, 17 October 2012 (UTC)

Windows Server 2008

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 209.143.2.97 (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?

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. —92.27.34.75 (talk) 17:16, 25 March 2013 (UTC)

Difference between "free space bitmap" and regular?

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?

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? --97.100.228.74 (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

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 (2⁷⁶ 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 142.68.60.234 (talk) 16:02, 7 October 2009 (UTC)

Invalid Patent

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

Why not NTFS?

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 Cole • t • c 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)

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

exFAT project

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

Merger proposal

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 Kourlas^{talk – contribs} 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)

• 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 Kourlas^{talk – contribs} 17:12, 10 June 2010 (UTC)

Suited especially for USB flash drives?

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 190.167.166.74 (talk) 20:08, 14 November 2011 (UTC)

New Apple Computers

The most recent Mac Mini and iMac 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 (talk • contribs) 14:53, 1 October 2010 (UTC) Sorry BrianDGregory (talk) 15:13, 1 October 2010 (UTC)

Add comparative speed differences: FAT > exFAT>> NTFS

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

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 (talk • contribs)

Operating System Specifications

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 (talk • contribs) 04:23, 7 January 2011 (UTC)

Specifications?

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

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

exFAT ships on all SDXC Cards, SD Card Association Link is broken. — Preceding unsigned comment added by 101.108.38.249 (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."

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)