Bug 242225 - "fstyp -l" does not report exfat filesystem volume label
Summary: "fstyp -l" does not report exfat filesystem volume label
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs mailing list
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2019-11-25 16:17 UTC by Victor Sudakov
Modified: 2019-11-28 09:43 UTC (History)
3 users (show)

See Also:


Attachments
Fixes the bug and adds matching test case (13.74 KB, patch)
2019-11-27 20:52 UTC, Conrad Meyer
no flags Details | Diff
Fixes the bug and adds matching test case, v2 (13.75 KB, patch)
2019-11-27 20:56 UTC, Conrad Meyer
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Victor Sudakov 2019-11-25 16:17:55 UTC
"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
#
Comment 1 Conrad Meyer freebsd_committer 2019-11-25 17:49:37 UTC
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.
Comment 2 Conrad Meyer freebsd_committer 2019-11-25 17:52:50 UTC
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).
Comment 3 Conrad Meyer freebsd_committer 2019-11-25 19:16:07 UTC
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.
Comment 4 Victor Sudakov 2019-11-26 02:11:57 UTC
(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?
Comment 5 Victor Sudakov 2019-11-26 02:15:36 UTC
(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?
Comment 6 Conrad Meyer freebsd_committer 2019-11-26 03:36:44 UTC
(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.
Comment 7 Victor Sudakov 2019-11-26 04:27:24 UTC
(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.
Comment 8 Conrad Meyer freebsd_committer 2019-11-26 04:40:28 UTC
"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.
Comment 9 Victor Sudakov 2019-11-26 04:45:28 UTC
(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.
Comment 10 Victor Sudakov 2019-11-26 04:53:07 UTC
(In reply to Conrad Meyer from comment #8)
Separate bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242243
Comment 11 Conrad Meyer freebsd_committer 2019-11-27 20:52:14 UTC
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.
Comment 12 Conrad Meyer freebsd_committer 2019-11-27 20:56:28 UTC
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.)