Mail Archives: opendos/1998/02/02/16:35:10
> >Mind you, the passwords also break under Long FileNames, because they use the
> >same flags to signal what they are.
>
> I realize it's way too late to ask this, but ... why duplicate Microsoft's
> funky LFN disk storage? It's a *bad* standard, and incompatible with
> low-level disk utilities, including Microsoft's own 6.2x DEFRAG and
> SCANDISK. Why not emulate the Microsoft Long FileName API, but store the
> long filenames in some sensible way, similar to say a 4DOS DESCRIPT.ION
> file? Would maintain compatibility with the DR DOS passwords, among other
> things.
>
> #bitchmode OFF
>
> Okay, I do realize it's too late to change the strategy. I just like to
> complain.
I don't think it is too late exactly - programs that use the LFN API
shouldn't notice if the way the directory structure is written to disk
is totally different, so somebody could come along with a better way of
storing files on disk (and still be able to read MS's diskettes)
without problems at that end. The only trouble would be for people
writing new filesystem drivers, since there isn't an easy way yet to
"slot in" alternative drivers - you have to take over interrupt 21h and
work out if this call applies to your disk because there is no IFS
yet.
In fact there is no long term problem with retaining the DRDOS password
protection system API either, even if there are different ways of
storing the passwords/permission flags on disk. The only concern might
be that it would be nice to use some fields in the LFN structure
returned by the API which are set aside for permission flags yet could
get redefined by MS any time. And even with the (V)FAT structure it is
possible to detect whether the fields in the directory entry are used
for password information or extra datestamp information with a success
rate better than MS's own checksum method for trying to make sure SFN's
and LFN's match up correctly.
I keep promising to write a new file system (well, I've got it
"working" nicely on paper!) but it probably will be a while before I
can do anything useful - mainly because I'd have to go to a lot of work
in areas of interfacing to the operating system which wouldn't be
neccessary if there was an IFS similar to Linux and OS/2.
But ultimately I hope to see extensions to the operating system (that
don't need to take much RAM if overlays are used) that detect various
file system types and load the code needed as required for ext2fs,
vfat, hpfs, alfs, ntfs, vfs, etc. Such code could check diskettes as
they are used, and pull in the correct code automatically. It could
even check for viruses, provide a virtual file system for archive
formats, etc.
---------------------------------------------------------------------------
Mark Aitchison, \_ Phone: +64 3 364-2947 home 337-1225
Dept of Physics & Astronomy, </ Fax: +64 3 364-2469 or 364-2999
University of Canterbury, /) Web: www.phys.canterbury.ac.nz/~physmsa
Christchurch, NEW ZEALAND. (/' E-mail: M DOT Aitchison AT phys DOT canterbury DOT ac DOT nz
---------------------------------------------------------------------------
- Raw text -