When the vfat support was written, Windows 95 was not common.
The vfat code was also unstable, so many people wanted to avoid it.
> What if, instead of having the base FAT module and an MSDOS fs
> module and a VFAT fs module that load on top, have the FAT module
> be extendable? I mean, have the "standard" configuration be to use
> plain jane 8.3 MSDOS filenames, but have an extra config option to
> enable VFAT LFN support, and then when the LFN support is compiled in,
> have a mount-time option whereby LFN support can be disabled for
> specific mounts.
By default, the name should be "fat" and it should autodetect
the vfat and umsdos extensions. The gross vfat filesystem requires
a gross kernel hack: look for a win* directory with long filenames.
Then look for a linux directory and do the umsdos pseudoroot.
The umsdos pseudoroot should always operate to make recovery easy.
Without the pseudoroot, many more symlinks break.
The "msdos", "vfat", and "umsdos" names can be equivalent to
"fat" with mount options to disable or force various features.
There is a need to support the new FAT32 filesystem.
Thought: the FAT filesystem code has grown too big and complex.
Nobody would want to rewrite it, because then all the strange
code must be tested again - maybe. Must we still support DOS 3.1
disk manager hacks? The text file translation makes the code
complicated and very ugly. Microsoft has added new things recently,
including FAT32 and a dirty flag. I think the linux driver would
run much faster if it kept the whole FAT in RAM and built some
decent data structure in RAM to shadow the FAT data.
Right now, mtools is 4x as fast as the kernel filesystem.
I tested a file copy of 700 kB on a 1.44 MB floppy disk and
a file copy of 4 MB on a 96 MB Zip disk. In both cases,
mtools was about 4x faster.