Messages in this thread |  | | From | Albert Cahalan <> | Subject | Re: RFC: Modified FAT filesystem driver? | Date | Mon, 2 Dec 1996 10:07:06 -0500 (EST) |
| |
From: rnichols@interaccess.com (Robert Nichols) > Marc MERLIN <merlin@magic.metawire.com> wrote: >> In article <199611230035.TAA03352@denali.ccs.neu.edu>, >> Albert Cahalan <albert@ccs.neu.edu> wrote: >> >>> I think you can always find a long filename in win*/desktop, >>> or whatever they call it. > [SNIP] >> My point is just that this kind of autodection would have _many_ >> reasons to fail. For many people, a mount option would be the only >> reliable option. > > Exactly. There is no requirement that a VFAT file system actually > contain any files with long names. What would happen if you were to > 'rm' the last long-named file from the file system and unmount it? When > you mounted it again would you want it to come back as FAT instead of > VFAT (and now you can't re-create the file that you just deleted)?
It does not matter if there are many reasons it can fail. It is a heuristic, and heuristics do fail sometimes. You can always override the heuristic by mounting as vfat, msdos, umsdos, dmsdos, or uvfat.
If there was a "fat" filesystem that would autodetect, Linux distributions would not need to worry the matter. When the distribution assumes a plain msdos filesystem, Windows 95 long filenames get messed up. When the distribution assumes a vfat filesystem, DOS scandisk will complain.
Note that the Windows 95 installer does not modify /etc/fstab! If Linux would autodetect the filesystem subtype, then there would be no need to modify /etc/fstab. Oh, let's try to not torture newbies too much. Expecting a newbie to modify /etc/fstab after a Windows upgrade is like expecting them to hack the registry.
|  |