GNOME Bugzilla – Bug 639760
exfat / fat64 support?
Last modified: 2017-01-13 15:53:09 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.