www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/10/23/02:29:25

From: <SANDMANN AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: LFN under W95
Date: Tue, 22 Oct 1996 10:32:34
Organization: Rice University, Houston, Texas
Lines: 19
Message-ID: <326ca2c2.SANDMANN@clio.rice.edu>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 961022081452 DOT 2800M-100000 AT is>
Reply-To: SANDMANN AT clio DOT rice DOT edu
NNTP-Posting-Host: clio.rice.edu
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

>  ren Makefile Makefile~
> 		This renames it to `Makefile~', but the short name stays
> 		`MAKEFILE'.  This is a bug IMHO.

Read the documentation for W95 LFN handling.  The problem is that files
under W95 have TWO names each.  You can refer to it with either name.
This is the reason the default numeric tail value is 1, so the short names
are always messed up and pretty useless (but don't conflict either).  If you 
don't ever use any LFN unaware programs, leave the numeric tail value in
the registry as it is shipped.

You have an expectation which file names will match one to one which isn't
correct under W95 - the example above is how I EXPECT W95 to behave, since
I have been messing with it since 1994 betas...  It isn't unix.

I would argue that programs that do the above rename and expect them to
be unique are broken under W95 and should be changed to use a ".extension"
change instead.  Just because some unix programs make really bad assumptions
on file name behavior doesn't mean W95 is buggy.

- Raw text -


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