delorie.com/archives/browse.cgi   search  
Mail Archives: opendos/1997/05/31/05:14:49

Date: Sat, 31 May 1997 05:08:20 -0400 (EDT)
From: "Mike A. Harris" <mharris AT blackwidow DOT saultc DOT on DOT ca>
Reply-To: "Mike A. Harris" <mharris AT blackwidow DOT saultc DOT on DOT ca>
To: John Fremlin <dfremlin AT facstaff DOT wisc DOT edu>
cc: opendos AT delorie DOT com
Subject: Re: Case sensitive filesystem
In-Reply-To: <QX+cz8ew4imP092yn@facstaff.wisc.edu>
Message-ID: <Pine.LNX.3.95.970531044440.3136u-100000@capslock.com>
Organization: Total disorganization.
MIME-Version: 1.0

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" <mharris AT blackwidow DOT saultc DOT on DOT ca> 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?

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019