[Bug 252787] fstyp heuristics can misidentify UFS file systems created by newfs, goofs up autofs's special_media map

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252787

            Bug ID: 252787
           Summary: fstyp heuristics can misidentify UFS file systems
                    created by newfs, goofs up autofs's special_media map
           Product: Base System
           Version: 12.2-STABLE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: bin
          Assignee: bugs at FreeBSD.org
          Reporter: kreuter at progn.net

Created attachment 221685
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=221685&action=edit
Demonstrate fstyp's failure to detect UFS on a suitably evolved volume

The code fstyp uses to detect FAT and EXFAT look for magic strings in a block
that UFS doesn't use, and fstyp checks for FAT formats before UFS. Together,
these have consequence that fstyp will misidentify the file system type on a
volume that has at one time been formatted with either of those formats and is
then reformatted with newfs without any intervening operation that overwrite
the first block on the volume. Reproduction attached.

Next, while I haven't reproduced, it looks as if the same issue will apply to a
volume that was once NTFS formatted (because the NTFS magic string is in the
same location, and the check for NTFS precedes the one for UFS).

Finally, because the default autofs special_media map uses fstyp to guess the
file system format on a volume, this combined behavior of newfs & fstyp
suffices to render such a file system unmountable by that map (though the
volume is mountable manually). 

I ran into this issue on a recently purchased USB storage device after changing
the MBR slice type (but not the slice's size) and creating a UFS file system on
that slice using newfs, only to find that the automounter couldn't mount the
volume.

Anyway, it's easy enough for a user to fix a given volume by overwriting some
bytes where FAT/EXFAT/NTFS stores its magic string, so perhaps this is just a
documentation issue, perhaps for the fstyp man page. (It's not clear to me that
any of newfs, fstyp, or the special_media map is doing anything wrong. But they
happen not to combine to achieve the desired result in this specific scenario,
so something seems to want improvement.)

-- 
You are receiving this mail because:
You are the assignee for the bug.