Date: Tue, 03 Feb 1998 10:04:39 +1300 From: physmsa AT cantua DOT canterbury DOT ac DOT nz (Mr M S Aitchison) Subject: Re: LFN & password protection (was re: Re: some problems ) To: opendos AT delorie DOT com Message-id: <199802022104.KAA10979@cantua.canterbury.ac.nz> Precedence: bulk > >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,