delorie.com/archives/browse.cgi   search  
Mail Archives: opendos/1997/02/07/22:46:39

Date: Fri, 7 Feb 1997 21:31:31 -0600 (CST)
From: "Colin W. Glenn" <cwg01 AT gnofn DOT org>
To: "'OpenDOS newsgroup'" <opendos AT mail DOT tacoma DOT net>
Subject: Re: [opendos] Filesystems/Long Filename API
In-Reply-To: <c=US%a=_%p=SSG%l=SITE2S1-970207201506Z-29534@site2s1.sbservices.com>
Message-ID: <Pine.GSO.3.95.970207212427.21429E-100000@sparkie.gnofn.org>
MIME-Version: 1.0
Sender: owner-opendos AT mail DOT tacoma DOT net

On Fri, 7 Feb 1997, Jonathan Tarbox - SSG wrote:

> 	The thing is, true we all hate the way Win95 hashes the Long Filename
> down to 8.3 standard, but if we then change this method for OD will not
> Win95 not comprehend it when we go back into Windows?  What's so hard to
> have our DIR and other basic DOS internal commands to list both the LFN
> and hashed 8.3 name..  

Which is what I'm implying for the new hash rules, we could keep in in
conformity with WIN(% and even take it one step further.  Seeing that
we're re-writing the OS to support LFN's, and should we decide to do it
W(% style, the instead of using method of:

snag first six alpha chr's
tack on ~#

we instead:

snag first three alpha chr's of first word
take first letter of next three words
tack on ( ~# ) or ( ## ) (as an option, I hate '~' in a filename)

Not only do I think this is workable, it will produce a more meaningfull
8.3 name over what W(% does, and as long as we stick with the rules, we
could even create a utility which would allow us to reconstruct current
names without crashing W(% LFN support!


- Raw text -


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