Talk:ExFAT

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)

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. —92.27.34.75 (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 82.68.15.142 (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. ----

FAT+?

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 99.109.253.206 (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

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. 84.209.119.158 (talk) 00:07, 10 February 2015 (UTC)

exFAT is now GPL2! :-D

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

So it's free software.

http://www.linuxuser.co.uk/news/samsungs-exfat-linux-driver-now-gpl-compliant

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

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

There is not a knob like NTFS/ReFS DisableDeleteNotify in the driver, so nobody knows for sure. The Swissbit manual claims that it does. It mentions a custom SMART value for TRIM usage (freed blocks%). The trimcheck guys think Windows does not.

We can probably check for ourselves using less direct measurements the Linux nvme smart-log-add command prints out nand/host_bytes_written values that allows one to look at write amplification. For a given drive one could probably do an experiment by noting the growth of these two values on a ExFAT filesystem that has been filled, cleared, and a bit of writes done on Windows. Or a VM could just catch those commands going to its virtual SSD. (Yes, that would be original research.) --Artoria2e5 🌉 09:16, 17 November 2019 (UTC)

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

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

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 http://msdn.microsoft.com/en-us/library/ee490605(v=winembedded.60).aspx

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 (talk • contribs) 17:33, 4 June 2014 (UTC)

Number of Files per directory

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 (talk • contribs) 17:58, 4 June 2014 (UTC)

Patent details

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

exFAT quirks

FYI - http://forum.osdev.org/viewtopic.php?f=1&t=30992 - • Sbmeirow • Talk • 02:08, 7 November 2016 (UTC)

last character of Directory cannot be Space = U+0020

"Naming Files, Paths, and Namespaces (Windows)". Msdn.microsoft.com. August 26, 2013. Retrieved September 17, 2013.

Xb2u7Zjzc32 (talk) 07:14, 10 May 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 4 external links on ExFAT. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Corrected formatting/usage for http://windowsteamblog.com/blogs/windowsvista/archive/2008/10/24/windows-vista-service-pack-2-beta.aspx
• Added archive https://web.archive.org/web/20130507183540/http://www.microsoft.com/en-us/legal/intellectualproperty/IPLicensing/Programs/exFATFileSystem.aspx to http://www.microsoft.com/en-us/legal/intellectualproperty/IPLicensing/Programs/exFATFileSystem.aspx
• Added archive https://web.archive.org/web/20101221232444/http://www.microsoft.com/about/legal/en/us/IntellectualProperty/IPLicensing/Programs/exFATFileSystem.aspx to http://www.microsoft.com/about/legal/en/us/IntellectualProperty/IPLicensing/Programs/exFATFileSystem.aspx
• Added archive https://web.archive.org/web/20110120184126/http://www.sdcard.org/developers/tech/sdxc to http://www.sdcard.org/developers/tech/sdxc

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 01:46, 26 September 2017 (UTC)

Contradiction?

Doesn't this:

exFAT can be used where the NTFS file system is not a feasible solution (due to data structure overhead), yet the file size limit of the standard FAT32 file system (viz., 4 GiB) remains.

...contradict this from Overview:

"exFAT allows individual files larger than 4 GiB..."

I find the first quoted statement suggests that there is a 4GiB file size limit for exFAT. — Preceding unsigned comment added by Riph72 (talk • contribs) 20:36, 19 March 2018 (UTC)

Wrong filesize limit

According to all sources, including the NTFS website, ExFAT supports upto 16EB filesizes, not the 4GB limit from Fat32. http://www.ntfs.com/exfat-comparison.htm Grez868 (talk) 19:18, 30 March 2018 (UTC)

Update/clarification needed on ExFAT, the Linux kernel, and MS's current licensing position.

We need to clarify how Microsoft helping add ExFAT support to the Linux kernel changes it's stance on ExFAT's licensing requirement status. If I understand the new stance by Microsoft then that means that all Linux kernel based OS's will be able to support ExFat without needed to license it. But how will this apply to non-Linux kernel based OS's. Will Apple still need a license for MacOS ExFAT support. What about any other non-Linux OS? Is this just a special deal for the Linux kernel only? --Notcharliechaplin (talk) 18:44, 27 September 2019 (UTC)

pre-allocation

As noted in the article, and elsewhere, pre-allocation is possible.

Does anybody know anything about actual implementations? Like MS file systems? How much pre-allocation is being done? — Preceding unsigned comment added by 203.206.162.148 (talk) 03:17, 21 October 2019 (UTC)

"double seconds" unclear/nonsensical

The page currently says, "Timestamp granularity for last-access time to double seconds (FAT had date only)."

The "double seconds" in there doesn't seem to make sense. ("double seconds" there doesn't seem to make sense as regular English, and it doesn't seem correct as a reference to a data type named "double" (for double-precision floating-point numbers) since times are stored using integers).

That that meant to be "two seconds"? 100.36.43.88 (talk) 16:28, 12 January 2023 (UTC)