Talk:ExFAT

message: 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)
thread_title:  Operating System Specifications 

message: 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)
thread_title:  Specifications? 

message: 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)
thread_title:  Devices capable to read exFAT 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  "As in FAT, when creating a file of known length, exFAT must perform a complete physical write equal to the size of the file." 

message: 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)
replies: text: 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)
thread_title:  Article gives readers wrong impression, conflicts with related articles, needs significant rework 

message: 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)
thread_title:  Files not recognized by some devices with large exFAT-formatted USB flash drives 

message: 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)
thread_title:  Flash Friendly Issues 

message: 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)
thread_title:  Number of Files per directory 

message: 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.
Cheers.—InternetArchiveBot (Report bug) 01:46, 26 September 2017 (UTC)
thread_title:  External links modified 

message: 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)
thread_title:  Contradiction? 

message: 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)
thread_title:  Wrong filesize limit 

message: 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)
thread_title:  Update/clarification needed on ExFAT,  the Linux kernel, and MS's current licensing position. 

message: 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)
thread_title:  pre-allocation 

message: 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)
thread_title:  "double seconds" unclear/nonsensical