GNOME Bugzilla – Bug 639760
exfat / fat64 support?
Last modified: 2018-02-04 22:43:48 UTC
I haven't found any related bug to this, so.. please consider including exfat fuse module support to integrate exfat / fat64 in gparted. You're probably informed, but here some very informative links about exfat linux-related progress: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/315710 http://code.google.com/p/exfat/ ( from comment https://bugs.launchpad.net/ubuntu/+source/linux/+bug/315710/comments/27 )
Thank you for raising this enhancement request. The following forum post includes a request for exfat support: exFAT (aka FAT64) http://gparted-forum.surf4.info/viewtopic.php?id=13428 The following wikipedia article indicates that there might be some licensing issues with exfat: exFAT http://en.wikipedia.org/wiki/ExFAT Microsoft IP licensing - exFAT File System http://www.microsoft.com/about/legal/en/us/IntellectualProperty/IPLicensing/Programs/exFATFileSystem.aspx
I'm the developer of fuse-exfat project mentioned above. I'm not a US citizen, so I didn't pay much attention to the US patents issues. AFAIK there is a (pending?) patent US 2009/0265400 filed by Microsoft that describes exFAT. So, I'm afraid that any exFAT implementation (including fuse-exfat) cannot be used in the US without license from Microsoft. But why is this an issue for GParted? As far as I can see GParted calls external tools to manage file systems. There is no need add any patented stuff to GParted code to support exFAT in it. Please correct me if I'm wrong.
Thank you Andrew for your interest in GParted and the work you have done with exFAT. I will begin by stating that I am not a lawyer, nor do I proclaim to be an expert in legal matters. As such the following are my interpretations, which could be wrong, and should not be regarded as legal advice. Now with that out of the way... :-) I believe you are correct. Licensing is not an issue for the GParted application because GParted would simply call external exFAT tools. I do not think a simple call to an external tool constitutes a violation of the licensing agreement. However, this would not be the case with the GParted Live CD image. GParted Live includes all the necessary software to use all of the features of GParted. Due to licensing constraints, we would not be able to include exFAT tools in the image (i.e., without having paid for the appropriate license). ;-( For discussion sake, let us assume that there are no licensing issues. From a quick perusal of the fuse-exfat source code I think that fuse-exfat enables an operating system, such as GNU/Linux, to: 1) Check an exFAT file system 2) Mount/unmount an exFAT file system 3) Read files and folders from an exFAT file system 4) Write files and folders to an exFAT file system. These are very useful features, but are these features enough to add to a partition editor? The ability to check an exFAT file system is certainly useful. However, without the ability to at least create or resize an exFAT file system, there is very little added functionality for an end user. At this point in time, the only feature I think it makes sense to add to GPArted is the detection of exFAT file systems to GPArted. I believe that a patch exists for adding detection to libblkid: http://www.spinics.net/lists/util-linux-ng/msg03202.html If I have made any mistakes or incorrect assumptions in the above response then please do let me know. I value your opinion.
I'm not a lawyer either, but I think you are right. OK, let's move on to technical issues that look much more attractive for me. :) I have already added mkexfatfs utility to the trunk (I'm going to release it soon). So we have the ability to create exFAT file systems. Resizing is a useful feature but quite complex. I don't think it will be implemented soon. Please tell if there are any other features that partition editor can employ. The patch for libblkid was included into util-linux-ng 2.18. Does GParted need anything else except blkid utility to detect exFAT? Any thoughts and suggestions are welcome.
Cool! Being able to create an exFAT file system is a huge plus. The features that GParted supports for file systems can be viewed at the following link: http://gparted.org/features.php For most file systems, GParted handles the moves and copies. Exceptions to this are FAT16/32, NTFS, and XFS where other libraries and tools provide these capabilities. It would be helpful if mkexfatfs (or mkfs.exfat) were able to add a volume label at the time of file system creation. Also useful would be a utility to change a volume label (and perhaps UUID) on an existing exFAT file system. Since GParted needs to know used and unused sectors (READ functionality in the matrix), it would be useful if this information could also be determined and accessed. Perhaps via a command that displays information somehow like btrfs-show does?
(In reply to comment #5) > It would be helpful if mkexfatfs (or mkfs.exfat) were able to add a volume > label at the time of file system creation. It's already able. > Also useful would be a utility to change a volume label (and perhaps UUID) > on an existing exFAT file system. I'll create such utility, it's simple. > Since GParted needs to know used and unused sectors (READ functionality in the > matrix), it would be useful if this information could also be determined and > accessed. Perhaps via a command that displays information somehow like > btrfs-show does? I think it would be easy to implement such functionality. I'll have a look at btrfs-show. Thank you for explanation. I'll log the progress in this bug.
(In reply to comment #6) > (In reply to comment #5) > > Since GParted needs to know used and unused sectors (READ functionality in the > > matrix), it would be useful if this information could also be determined and > > accessed. Perhaps via a command that displays information somehow like > > btrfs-show does? > > I think it would be easy to implement such functionality. I'll have a look at > btrfs-show. Tools exist for many file systems to show details about a file system. For ext2 file systems, GParted uses the "dumpe2fs -h /path-to-partition" command. Please note that the exact format of the output is not critical, as long as the output can be parsed consistently to extract the necessary information.
I've finally finished implementing the required functionality. So, now we have (in svn trunk, http://exfat.googlecode.com/svn/trunk): 1. exfatfsck <device> Checks FS validity. Cannot repair. 2. mkexfatfs [-i volume-id] [-n label] [-s sectors-per-cluster] <device> Creates a new FS. Sets volume label (15 chars max) if the -n option was specified. 3. exfatlabel <device> [label] Prints (if label was not specified) or sets (if label was specified) volume label. Like e2label. 4. dumpexfat [-s] [-u] <device> Prints detailed information about FS. All sizes are in bytes. Total FS size = "Sectors count" * "Sector size". Free FS space = "Free sectors" * "Sector size". Do not rely on "Allocated space" parameter. The -u option makes dumpexfat print ranges (in the form of N-M, including) of used sectors starting from 0 and separated with spaces. Output example: Volume label Volume serial number 0x636b9ad6 FS version 1.0 Sector size 512 Cluster size 4096 Sectors count 2048 Free sectors 328 Clusters count 239 Free clusters 41 First sector 0 FAT first sector 128 FAT sectors count 8 First cluster sector 136 Root directory cluster 5 Volume state 0x0000 FATs count 1 Drive number 0x80 Allocated space 0% Used sectors 0-183 192-263 272-343 352-399 480-511 520-591 600-671 680-751 760-831 840-919 928-999 1008-1079 1088-1159 1168-1223 1304-1327 1336-1407 1416-1487 1496-1575 1584-1655 1664-1735 1744-1815 1824-1903 1912-1983 1992-2039 Please have a look at those utilities and let me know if their output format is inconvenient.
*** Bug 661745 has been marked as a duplicate of this bug. ***
Initial support to detect exfat file systems has been committed to the git gnome repository for inclusion in the next release of GParted. The relevant git commits can be viewed at the following links: Add detection of exfat file systems (#639760) http://git.gnome.org/browse/gparted/commit/?id=7cbc125a2e9d26999c18f7a1539d96ed61a81f5c Add missing exfat file system to set_proper_filesystem method http://git.gnome.org/browse/gparted/commit/?id=284cfa7ed950d259b2c1a8e5409a73898fc4f586
Created attachment 199737 [details] [review] Diff file with updates to add exfat support to GParted Thank you Andrew for your work and the information in comment #8. Based on your detailed information I have created a "git diff" that adds exfat support to GParted. Please note that this diff file requires testing. The diff file was created with the following command: git diff > add-exfat-support-to-gparted.diff The diff file can be applied to the latest gnome git repository for GParted with the following command: git apply add-exfat-support-to-gparted.diff This diff has not been committed to the gnome git repository for GParted due to concerns regarding patents and licensing around the exfat file system.
An enhancement to detect exfat file systems was included in the GParted 0.10.0 release on November 1, 2011.
Hi Curtis, Would you commit an up to date patch to GParted app which fills out support for exFAT using the exfat-utils commands, if I submit one? It would add support for creation, checking, labelling and reading usage when unmounted. Thanks, Mike
If all of the major GNU/Linux distributions were distributing the ability to create exFAT file systems, then I would consider doing the same with GParted and GParted Live. Unfortunately this is not the case. Red Hat in particular has decided not to distribute exfat-utils. See: Review Request: exfat-utils - Utilities for exFAT file system https://bugzilla.redhat.com/show_bug.cgi?id=822049 Review Request: exfat - Free exFAT file system implementation https://bugzilla.redhat.com/show_bug.cgi?id=822046 As such I am closing this report as RESOLVED - WONTFIX. Thanks to all for your efforts in this area. Hopefully someday soon software patent laws will be changed for the better.
*** Bug 701317 has been marked as a duplicate of this bug. ***
It seems like exfat-utils is included in Debian, Ubuntu, Arch Linux and probably other distros currently, so I think it would make sense now to support exFAT when these are available?
Hi Jan, As far as I know, the licensing situation with exFAT has not changed. If this is not the case then please let me know. Some major distros include exFAT support, but not all. Comment #14 is still how I interpret the current situation. Curtis
I agree that including it on the GParted Live images might be an issue when distributing them in the US (or other countries that allow pure software patents), although that could also be solved by providing a US and a non-US download, and/or by making it easy to install 'exfat-utils' in a live session (at the user's responsibility, of course). But why make it impossible to use 'exfat-utils' in GParted when it is available? We can assume that people who have it installed deliberately installed it... And certainly we can't violate any law as long as we don't include any exfat code ourselves. (I'm not even sure if 'exfat-utils' actually violates any patents; 'exfat-fuse' is more likely to do so.)
You can compare this with the libdvdcss library: almost no distro includes it, but all applications that can play DVDs use it when it's available. Or how all media players will use installed codecs for patented formats when they are available (even when many distros don't install them by default).
First, my disclaimer: I am not a lawyer, nor do I proclaim to be an expert in legal matters. As such the following are my interpretations, which could be wrong, and should not be regarded as legal advice. Now back to the discussion... The fact that Red Hat/Fedora does not include exFAT speaks volumes to me. With respect to open source and exFAT licensing see also: Wikipedia - exFAT https://en.wikipedia.org/wiki/ExFAT#Restrictive_licensing_and_software_patents Microsoft - exFAT https://www.microsoft.com/en-us/legal/intellectualproperty/mtl/exfat-licensing.aspx I believe the following quote from the second reference is relevant. It is important to note that open source and other publicly available implementations of exFAT do not include a patent license from Microsoft. A license is required in order to implement exFAT and use it in a product or device. Until the licensing changes, or someone pays for an exFAT license, I believe it is best to leave exFAT support at detection only.
"Until the licensing changes, or someone pays for an exFAT license, I believe it is best to leave exFAT support at detection only." Why? Even if someone else can get in trouble for distributing exfat-utils, GParted can't be faulted for using it. And the fact that canonical includes it in Ubuntu, and hasn't been sued speaks volumes. It is easy to write on a web page that open source implementations are not licensed but if they really had a case, they would have proven it in court.
My position remains unchanged.
Again, why? You seem to be using a totally different standard here than for any of the other filesystems that most distros do not have support for, yet gparted handles.
This is a legal issue. It represents risk to the project.
I'm not a lawyer either, but as a citizen of the world I want to give my opinion. I believe there is no problem in making a fork of gparted and add the existing exfat support. Being limited because of a pathetic pure software patent system makes no sense at all. The world is much bigger than that. Exist a space for those who are free in fact and for those who think that they are free.
This is not related to patents, as none of the code in GParted would violate any exFAT patents.
We create and maintain GParted Live to enable you to use all the features of the latest versions of the GParted application. There are legal issues if the exFAT code is included in either GParted Live or any other Live image as can be seen in the linked articles above.
Since Samsung released GPLed versions of the exfat code in 2013, does that change the situation in any way? Software Freedom Conservancy announcement here: https://sfconservancy.org/news/2013/aug/16/exfat-samsung/ Samsung GPLv2+ Code release here: https://gitorious.org/binbang/exfat-linux As I understand it, that code contains the "(at your option) any later version" clause, which means I can choose GPLv3. Utilising GPLv3 means that Microsoft or Samsung cannot exclude us from using or distributing the code by means of a patent license.
If Samsung released it that doesn't affect Microsoft's patents; they could still sue, but the fact that they haven't after all of these years is both a pretty good indicator that they won't, and if they ever do, significantly weakens their legal argument.
Thanks Phillip for indicating that the Patents are still in effect. @Tudor there is no change in our position.
@Phillip You're right, but it's not a case of weakness. SFC legally challenged Samsung's implementation from which they had two options - remove the GPL code or distribute their implementation as GPL. They chose the latter. (Additionally, they didn't just choose the latter, they chose the "Or Later" option, too!) If anyone else were to distribute or build on that code then the person sued would be the original distributor and modifier of the license, Samsung, since every receiver would just point to that as the reason for their use of the code. Microsoft could, technically, issue a cease-and-desist but, in doing so, they would also have to sue Samsung and prove that they breached an agreement to which we were not privy. The fact is, there is code distributed by Samsung, and it is GPLv2+. It's their responsibility. We shouldn't be second-guessing the components of their agreement as it makes the GPL look weaker than it is.
BTW, https://fsfe.org/campaigns/gplv3/patents-and-gplv3.en.html#Explicit-patent-grant
I don't know what weakness or agreement you are referring to. It doesn't matter who wrote or licensed the code; if you are distributing it and it violates patents, you can be sued. On the other hand, as I have said before, simply teaching gparted how to use the exfat tools without actually distributing them isn't even remotely something you can get in trouble for.
As I understand it, we can't be sued. The GPLv3 explicitly provides a patent grant that protects all four freedoms relating to the code provided. Your suggestion was that extended amounts of use without intervention weakens Microsoft's legal argument. I'm arguing the opposite - the GPLv3 is the strength that gives us the right to use the code and there is an explicit patent grant for all perceived uses of that code "..nonexclusive, royalty-free and worldwide, and covers all patent claims you control or have the right to sublicense..." Samsung *may* be able to be sued by Microsoft for mislicensing the code, but that is not our concern. The code is published with a GPLv3 compatible license which explicitly provides the right to all four freedoms.
Samsung does not own the patent and so they can not grant a license.
Samsung has the right to sublicense by virtue of their products that contain the GPL code they published. Again, from GPLv3: "If you distribute a covered work knowingly relying on a patent license, you must act to shield downstream users against the possible patent infringement claims from which your license protects you." Nowhere has Samsung declared that there is a patent covering the use of the GPL published code and, furthermore, in the case where they are protected and us not, they are required to protect us against their oversight.
I guess that means that if Microsoft sued you, then you could sue Samsung, but no agreement between you and Samsung can compel Microsoft to grant you a license to their patent, and Samsung has no right to grant a license to Microsoft's patent.
I understand, and that's why I was pointing out that we're really second-guessing the agreement between Samsung and Microsoft. It may have a clause that includes allowing the license, since GPLv3 limits the use of the code to free software anyway and therefore isn't a commercial threat. I admit this is speculation, which is why I'd prefer to go by the published information they voluntarily attached to the code. Perhaps this requires a more formal query to Samsung to clarify the content of their agreement. I would be surprised, however, after 4 years if they knew what the content of that agreement was and, as pointed out earlier, there's enough use of their patent in the wild that it suggests Microsoft isn't that keen on enforcing it anyway.