Message-Id: <199702032215.XAA24518@magigimmix.xs4all.nl>
From: "Yeep" <Yeep AT xs4all DOT nl>
To: <jamesl AT albany DOT net>, "Colin W. Glenn" <cwg01 AT gnofn DOT org>
Cc: <dg AT dcs DOT st-and DOT ac DOT uk>, "OpenDOS Mailing List" <opendos AT mail DOT tacoma DOT net>
Subject: Re: [opendos] OpenDOS + Win95 w/FAT32? 
Date: Mon, 3 Feb 1997 22:58:50 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-opendos AT mail DOT tacoma DOT net
Precedence: bulk

> > > 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
> ?? ;-)

Despite the fact that Windoze sucks (terribly!) it does handle the
problem....pretty good (could be better, but I'm not smart enough to think
of a better solution :-)  ).
Whenever you have a file called "this_is_my_file" and a file called
"this_is_my_file_too", windoze names the first file "this_i~1" and the
second "this_i~2".
Off course there is a downside to this, I have a directory which contains
the files "d~1" to "d~a67fc7".
But other than that, the solution works, all files are saved under
different names.

	Yeep