Mount read-only works more or less correctly. Files and directories can be
traversed and read.
Contiguous allocations (one notable difference from FAT32) should work
correctly, although it is difficult to generate a test filesystem with any
contiguous files >1 block (fuse-exfat does not do a great job of creating these
Another notable different from classic FAT is that directories do not have
concrete . and .. entries. This means the canonical directory denode "inode
number" or dirclust+offset must be the parent directory's entry in exFAT, not
the self-referential '.' entry that our msdosfs(5) uses for classic FAT.
(exFAT directory entries are also in a different format and opposite order from
VFAT -- the exFAT file entry precedes its name entrie(s).)
Things that don't work or are known gaps:
- Any sort of mutation or writing (known gaps in inmem -> ondisk, free space finding in directories, etc).
- Decoding exFAT datetimes. This isn't very hard (some logic is trivally shared with the existing msdosfs time support) but wasn't essential for a proof-of-concept, so I haven't done it yet.
- '..' lookup -- I don't have any great ideas for implementing this without adding some per-mount cache datastructure with ugly locking. Or having child vnodes hold a ref on their parent and drop it during inactive or something (only works for lookup, not getfh).
- Input sanitization: forbidden characters in filenames.
- Some ugly copy-paste (readdir, lookup) where most of the logic is shared with classic FAT. This could be refactored into some shared routine (iterating dirents from some offset, for example).
- Per exFAT spec, implementations SHALL verify dirent-set checksum; we don't yet.
- Utilizing on-disk up-case table correctly.
- geom_label support for exFAT labels. We have the code for this in fstyp(8) already, just needs adaptation for geom. Similarly, for exFAT GUIDs (although we don't have this code in fstyp(8)).
- Utilize namehash in component lookup (performance-only; not a functional gap).
Copyright: I wrote this implementation from the published Microsoft
specification, and did not copy or reference any other implementation (e.g.,
the GPL-licensed fuse-exfat or GPL-licensed linux kernel implementation).
Patents: My understanding is that the three relevant exFAT patents (contiguous
files, namehash lookup, and the vendor-extension dirent design) are either
already expired or expire soon in 2021 or 2022. I'm not advocating for
enabling this in GENERIC at this time, but mostly because the implementation
still has so many gaps.