"fstyp -l" does not report exfat filesystem volume label. How to reproduce: First install sysutils/fusefs-exfat, then: # mkexfatfs -n EDGARPOE /dev/md0 mkexfatfs 1.3.0 Creating... done. Flushing... done. File system created successfully. # exfatlabel /dev/md0 EDGARPOE # fstyp -l /dev/md0 exfat #
Yes, it just does basic recognition of the filesystem at this time. 67 /* 68 * Reading the volume label requires walking the root directory to look 69 * for a special label file. Left as an exercise for the reader. 70 */ It's unclear if traversing the root directory of an exfat volume is covered under Microsoft's exfat patents.
Microsoft recently released the exfat patents to the Linux-centered OIN, which does *not* license them for use outside of Linux systems: https://cloudblogs.microsoft.com/opensource/2019/08/28/exfat-linux-kernel/ So we're still potentially in violation if we implement patent-covered portions of exfat in base. I don't know what parts are patented as I have not looked at the patent(s).
https://www.openinventionnetwork.com/joining-oin/linux-system/ OIN facilitates the sharing of patent rights between thousands of OIN community members, and the coverage for sharing is called OIN’s “Linux System”. The definition of the Linux System relevant to the OIN license agreement is described on this page and associated tables. ... “Linux Environment Component” shall mean any of the software packages whose released source code shall be identified on the OIN website, including bug fixes and error corrections thereto, or a Predecessor Release or Successor Release of any of such packages. “Linux System” shall mean a Linux Environment Component or any combination of such components to the extent each such component is (i) generally available under an Open Source License or in the public domain (and the source code for such component is generally available) and (ii) Distributed with, or for use with, the Linux Kernel (or is the Linux Kernel). ... The Linux Environment Components consist of the software packages identified below in Tables 1 and 2, as such packages’ currently-released source code as of November 8, 2005 is identified on the OIN website, and in Table 3, as such package’s currently-released source code as of May 1, 2012 is identified on the OIN website, and in Table 4, as such package’s currently-released source code as of October 31, 2012 is identified on the OIN website, and in Table 5, as such package’s currently-released source code as of September 10, 2013 is identified on the OIN website, and in Table 6, as such package’s currently-released source code as of March 7, 2014 is identified on the OIN website, and in Table 7, as such package’s currently-released source code as of June 25, 2015 is identified on the OIN website, and in Table 8, as such package’s currently-released source code as of July 13, 2017 is identified on the OIN website, and in Table 9, as such package’s currently-released source code as of January 17, 2019 is identified on the OIN website. ======================================================================== My (not a lawyer) read of this is that if we want coverage, we need to get fstyp(1) ported for use with the Linux kernel (which should be easy) and then also get OIN to list in in their Linux Components table, which may be more difficult.
(In reply to Conrad Meyer from comment #1) > Yes, it just does basic recognition of the filesystem at this time. Deserves mentioning in the BUGS section of fstyp(8), don't you think?
(In reply to Conrad Meyer from comment #2) > So we're still potentially in violation if we implement patent-covered portions of exfat in base. Well, /etc/autofs/special_media could use exfatlabel from sysutils/fusefs-exfat to obtain the label. Otherwise how are we going to show friendly labels in /media for exfat volumes?
(In reply to Victor Sudakov from comment #4) I wouldn't object, but I don't feel strongly about it: These options are available: -l In addition to filesystem type, print filesystem label if available. ^^ ^^^^^^^^^ (In reply to Victor Sudakov from comment #5) I don't know anything about special_media or whether it can depend on utilities outside of base. That's probably its own bug.
(In reply to Conrad Meyer from comment #6) > -l print filesystem label if available Well, the label IS available and exfatlabel proves that. > I don't know anything about special_media or whether it can depend > on utilities outside of base It already does, please look inside it.
"If available" can also mean "if this program is capable of reading it." I was not suggesting that exfatlabel was making up random labels for unlabeled volumes. Again, please file a separate bug against the special_media component. I don't have any familiarity with or interest in it. It's worth tracking the fstyp(8) bug independently.
(In reply to Conrad Meyer from comment #8) There is no mention in the PR header of special_media or anything else unrelated to "fstyp -l". If you think that fstyp works as intended, please feel free to close the PR.
(In reply to Conrad Meyer from comment #8) Separate bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242243
Created attachment 209495 [details] Fixes the bug and adds matching test case Here's a patch that adds the missing functionality, as well as a functional test using the existing exfat test image. It's not clear to me that we can commit it and ship it without drawing the ire of OIN's? Microsoft's? lawyers. So I do not intend to commit it myself.
Created attachment 209496 [details] Fixes the bug and adds matching test case, v2 (Obviously I did not actually run the test under ATF the first time around. This fixes the typo's in the atf-sh test case definition.)
A commit references this bug: Author: cem Date: Sun Dec 22 03:19:18 UTC 2019 New revision: 355996 URL: https://svnweb.freebsd.org/changeset/base/355996 Log: fstyp(8): Show exFAT volume labels with -l flag exfat is fundamentally the same design as fat32. The superblock differs marginally, and there are some additional optional features irrelevant to fstype(8); the structure of dirents has changed slightly to enable, among other things, larger files; the directory entries are no longer DOS 8.3 ASCII or local 8-bit encoding, but instead explicitly UCS-2-LE. (As a result, this change uses iconv to convert a found exfat volume label to the user's locale.) Locating the volume label is identical to FAT32: locate the root directory and walk through dirents until you find a volume label. Like FAT32, follow the FAT chain between root directory clusters as necessary. PR: 242225 Reported by: Victor Sudakov <vas AT sibptus.ru> Changes: head/usr.sbin/fstyp/exfat.c head/usr.sbin/fstyp/fstyp.c head/usr.sbin/fstyp/fstyp.h head/usr.sbin/fstyp/tests/fstyp_test.sh
Usually, we close bugs after MFC.
A commit in branch stable/12 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=58a9e1ca85797a050d3a39bffa6babcb9d3463a4 commit 58a9e1ca85797a050d3a39bffa6babcb9d3463a4 Author: Conrad Meyer <cem@FreeBSD.org> AuthorDate: 2019-12-22 03:19:17 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2021-02-02 21:12:04 +0000 fstyp(8): Show exFAT volume labels with -l flag exfat is fundamentally the same design as fat32. The superblock differs marginally, and there are some additional optional features irrelevant to fstype(8); the structure of dirents has changed slightly to enable, among other things, larger files; the directory entries are no longer DOS 8.3 ASCII or local 8-bit encoding, but instead explicitly UCS-2-LE. (As a result, this change uses iconv to convert a found exfat volume label to the user's locale.) Locating the volume label is identical to FAT32: locate the root directory and walk through dirents until you find a volume label. Like FAT32, follow the FAT chain between root directory clusters as necessary. PR: 242225 Reported by: Victor Sudakov <vas AT sibptus.ru> (cherry picked from commit 85b4c344c8c69ff7993bc0ac833aaf9a8108b88d) fstyp(8): Fix WITHOUT_ICONV build Reported by: olivier (cherry picked from commit 5ab1cb52b21fdc5524bd970e9b5cdff21a5bcabf) usr.sbin/fstyp/Makefile | 4 + usr.sbin/fstyp/exfat.c | 303 ++++++++++++++++++++++++++++++++++++- usr.sbin/fstyp/fstyp.c | 49 ++++-- usr.sbin/fstyp/fstyp.h | 7 + usr.sbin/fstyp/ntfs.c | 6 + usr.sbin/fstyp/tests/fstyp_test.sh | 10 ++ 6 files changed, 367 insertions(+), 12 deletions(-)