Message-Id: <199702030427.XAA29828@keeper.albany.net>
Comments: Authenticated sender is <jamesl AT mail DOT albany DOT net>
From: "Jim Lefavour" <jamesl AT mail DOT albany DOT net>
To: "Colin W. Glenn" <cwg01 AT gnofn DOT org>
Date: Sun, 2 Feb 1997 23:21:01 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: [opendos] OpenDOS + Win95 w/FAT32? 
Reply-to: jamesl AT albany DOT net
CC: dg AT dcs DOT st-and DOT ac DOT uk, OpenDOS Mailing List <opendos AT mail DOT tacoma DOT net>
Sender: owner-opendos AT mail DOT tacoma DOT net
Precedence: bulk

> On Sun, 2 Feb 1997, Jim Lefavour wrote:
> > I agree - the ext2 is the BEST fs that I have seen or heard of by
> > far.  But to do this, we must first provide for current
> > applications.
> 
> Well, how about finding a good middling ground, one which allows for
> LFN's, but includes a bit of test code to _ensure_ that selected
> LFN's contain a descent 8.3 name within?  To expand on this:
> 
> Say you have a fully qualified filename called:
> 
> > > [...]
> > > >I think that OpenDOS should progress in a NEW direction, by
> > > >adding somehthing like ext2 support STANDARD.  It may not work
> > > >with old
> > connectivity package).  We need not only to provide a superior fs,
> > but also to provide TRANSPARENT translation for programs accessing
> > [snip]
> 
> c:/thisone/second.level/real.filename.ext.z
> 
> Which the system will hand to a 8.3 program as:
> 
> c:\thisone\second.lev\realfile.z
> 
> Should you generate a file called:
> 
> c:/thisone/second.level/real.filelist.ext.z
> 
> The OS complains:
> 
> New filename conflicts with prior 8.3 name!
> 
> and shows you the conflict.  Should you chose to ignore the error,
> the system informs you:
> 
> Warning! 8.3 programs will only see first occurance of file!
> 
> Is this workable?
> 
Therein lies one problem with the lookup table approach - I have seen 
several packages using long "Linux" filenames in TGZ files, which use 
filenames that have large similar portions, viz.

open_file.c
open_file.h
open_file_mic.c
open_file_mic.h
...

(just a made up example)
I'm sure you get the idea, and you see the problem - either we will 
need user intervention to take care of this, as in "enter new file 
name: " or we will need to arbitrarily assign filenames that 
guarantee uniqueness and the FS may not decide that a file is 
"unimportant".  Also, what if:
c:\thisone\level.help\open_file.help
c:\thisone\level.help.source\open_file.help.txi
?? ;-)

Jim "Can't wait for next release" L.

jamesl AT albany DOT net or http://www.albany.net/~jamesl/