Date: Sat, 31 May 1997 05:08:20 -0400 (EDT) From: "Mike A. Harris" Reply-To: "Mike A. Harris" To: John Fremlin cc: opendos AT delorie DOT com Subject: Re: Case sensitive filesystem In-Reply-To: Message-ID: Organization: Total disorganization. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sat, 10 May 1997, John Fremlin wrote: > I've changed the thread name from "Re: BIG suggestion for OpenDOS > features" which was a bit misleading. > > "Mike A. Harris" typed: > [snip, file system controversy] > > > >Well, then you wouldn't enable case sensitivity on the new > >filesystem, or else you'd use FAT, or some other filesystem. I > >on the other hand would have the option of full case sensitivity, > >and I would use it too. > > How would this be implemented? > Pardon my filesystem ignorance, but wouldn't dir, move, copy and > almost any other file util for FAT be very different code from > the versions for ext2 or whatever? NO! The code in dir/move/copy, etc just asks dos to read the disk and supply it with the proper info, or tells dos to rename files, etc... Here is a scenario for the new system: DIR->DOS->VFS->FAT Assume that your current directory is on an FAT filesystem. DIR uses the DOS findfirst/findnext routines which would then request the lower level VFS (virtual filesystem layer) to call the appropriate findfirst/findnext for the filesystem of the current working directory (or supplied pathname,etc...). Therefore the VFS then calls the FAT code which returns the info to the VFS, then back to the DIR program. If ext2 was used, then the scenario would be: DIR ->DOS->VFS->ext2 Assuming that you were doing DIR on an ext2 drive (the exact same DIR program that you used for doing a dir on an FAT drive). DIR calls the DOS findfirst/findnext routines which request the VFS to call the appropriate filesystem code which happens to be ext2. The ext2 code does a findfirst/findnext, returns the info to the VFS layer and then back to the DIR program. For this to take place, a NEW VFS API would need to be created, and new utilities to use the new API (MOVE, DIR, REN, etc...). If you use the new utilities (supplied with the OS) then you would be able to use LFN's, symlinks, and whatever else the VFS is capable of. If you use OLD DOS 6.22 DIR/MOVE, etc... it will STILL WORK because a name mangling algorithm will be present in the VFS to allow compatibility with old legacy programs. This makes any new filesystem enhancements TOTALLY transparent to whatever software you are using. This includes case sensitivity. Quite simply, if a program uses the new API, it will be allowed to use all of the features of the new system, if it uses the old DOS 6.22 API (or DOS 3.3 for that matter) then it can't obviously make symlinks and such, however it will get 8.3 names from the filename mangler, and can delete copy move rename, etc... The system *IS* totally transparent. Even Window's 95 long filename API shows that it is possible (although it is a horrible hack of FAT, and the mangler is also horrible). Replacement commands for DOS 6.22 can EASILY allow you to use W95 VFAT LFN's, and similarly could extend to the OpenDOS VFS API. The VFAT API should also be supported in OD as a backwards compatibility layer too. > If so then poor souls who wanted case-sensitive would have > to download a lot of useless stuff for the guys who wanted > FAT. I don't understand what you mean. The *fortunate* souls who wanted case sensitivity would pick a case sensitive FS such as ext2 when installing OD, and would choose case sensitivity when formatting. Then they would go about their daily chores like usual. At first, legacy apps would only use the mangled names, but the VFS layer would maintain any LFN's that you create, then as more and more VFS aware programs exist, people will gravitate towards using them. If they don't WANT to upgrade to VFS aware programs, then they will have to use legacy apps and 8.3 names. This is certainly not an argument against VFS however. Lets say a VFS specific program comes along. Someone installs it on a case insensitive FAT system. The app still works because of the name mangler in the VFS (or probably in the C libs of the compiler that created the apps). The whole "problem issue" is moot however since you can see that even W95's shitty API is backwards compatible. The VFS will be MUCH more so, and much more compatible. > Maybe OpenDOS should come in different packages: one for > FAT, one for ext2 and one for both (perhaps even one for > VFAT). Well, that is a possibility, but I think that it would cause a lot of confusion since the only differences would be the presence or absense of the individual FS drivers. If you don't need EXT2 driver for example, don't use it, or choose not to even install the driver on your disk from the setup program. Since the driver is likely to be less than 10-20k, it is hardly necessary for multiple packages (of which there are allready enough). > PS: Couldn't this list be turned into a newsgroup? It's doubtful to happen. Many people have suggested it, and discussed persuing it, but I've yet to see an announcement. An alt.* group would not be useful do to the S/N ratio in those groups. The only thing that would be acceptible would be something like moderated groups such as: comp.os.opendos.developer comp.os.opendos comp.os.opendos.misc comp.os.opendos.answers comp.os.opendos.networking comp.os.opendos.setup etc... Mike A. Harris | http://blackwidow.saultc.on.ca/~mharris Computer Consultant | Coming soon: dynamic-IP-freedom... My dynamic address: http://blackwidow.saultc.on.ca/~mharris/ip-address.html Email: mharris at blackwidow.saultc.on.ca <-- Spam proof address Question: Where can I get a good WYSIWYG HTML editor for Linux?