I would favor a solution with two drivers. One has everything,
and the other only has plain 12-bit and 16-bit DOS filesystems.
> Albert Cahalan <albert@ccs.neu.edu> writes:
>
>> By default, the name should be "fat" and it should autodetect
>> the vfat and umsdos extensions.
>
> I'm not too thrilled with this idea--you could certainly modify
> supermount to look for the --linux-.--- directory and then remount
> as umsdos. However, I can have umsdos directories far down my
> hard disk, so would autodetect code do a full search of my partition
> looking for a --linux-.--- file? I have my laptop setup so that
> parts of a partition are umsdos enabled and other parts are not.
It should look in the most likely places. It is always a good idea
to let the user force and prevent detection, but autodetect should
be the default for type "fat", which is not mountable now.
> Similarly, detection of vfat filenames is not simple. Do I have
> to look all over the disk just to find a long filename?
You look in windows, win95, and winnt.
> Many times, Win95 installations have only 8.3 names because
> Microsoft still tends to squeeze everything into 8.3 names.
Programmer brain damage. :-)
I think you can always find a long filename in win*/desktop,
or whatever they call it.
> So how do I know the disk is vfat? (Actually, it may be easier now.
> In the past, WinNT didn't write out a long filename if a filename
> fit into an 8.3 name. I think W95 always writes out a long filename
> as well.)
The access time might be filled in.
>> The gross vfat filesystem requires
> ^^^^ (I think you mean umsdos)
No, I mean vfat (well, both actually).
>> 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.
>
> I've been very happy to have had umsdos around. When I had a laptop
> with a small harddrive, I couldn't afford to create a separate ext2
> partition. It might be a hack, but it has been a very useful hack for
> me. And I presume you will really hate my work on uvfat--sort of a
> hack on top of a hack.
I don't mind a gross hack when it is needed. I was actually suggesting
one: autodetection of the FAT extensions. It is gross, but very useful.
It would really help Linux distributions. Linux would also act right
when a DOS partition gets Windows 95 installed.
>> The "msdos", "vfat", and "umsdos" names can be equivalent to
>> "fat" with mount options to disable or force various features.
>
> So I need to waste all the space taken up by umsdos when
> all I really need is a simple msdos filesysetm? Sounds
> rather wasteful to me.
There is no simple msdos filesystem. I'd like one that just supports
12-bit and 16-bit FATs and 512-byte sectors. There would not even
be hooks for vfat and umsdos.
With that need taken care of, the standard version could become
as bloated as xemacs. :-)
>> 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.
>
> Keeping the fat in memory could help, but you would need to be careful
> with FAT32 disks. The fat could potentially get rather large.
If the kernel could mmap the FAT as a file, normal memory
management would take care of that problem. Isn't there a
trick that makes that work? I seem to remember that you
could save and restore one of the segment registers, or the
Linux 2.1 and non-i386 equivalent.
Advanced tricks would be easy with swappable kernel memory. If we
had that, the FAT could be shadowed in a B-tree structure that gets
swapped out. Maybe a hook into the swapper (not only for this!)
could let less used bits of the FAT data get thrown out when memory
runs low. (this assumes reads are more common)