Message-Id: <1.5.4.32.19961021103632.0067ac20@mv.mv.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 21 Oct 1996 06:36:32 -0400 To: Eli Zaretskii From: Howard Kaikow Subject: Re: HK: v 2.1 Cc: Howard Kaikow , djgpp AT delorie DOT com Yes, that proves that DJGPP does not really have LFN support. If it did, it would be looking at the long file name when LFN=y, not the short DOS name. I consider that to be a bug in the DJGPP LFN support. Edit is the built-in Edit program. At 08:16 AM 10/21/96 +0200, Eli Zaretskii wrote: >I probably failed to make myself clear enough, but your DIR output just >confirms what I suspected: it's Windows 95 fault! Look at the listing >above: the short 8+3 alias for `psbook.exe0' is `psbook.exe', not >something like `psbook~1.exe. Therefore, when the linker opens a file >called `psbook.exe', Windows overwrites `psbook.exe0' since as far as >Windows is concerned, a file called `psbook.exe' already exists! The bug >is in Windows 95 rename file function: it should have changed the 8+3 >alias when renaming the file, or else the file was not really renamed. >The new v2.01 library works around this bug in its `rename' function, so >if you use a program such as `mv' to rename files, this problem won't >happen. > >> 1. Make a text file, x.abc0 >> 2. open the file with Edit x.abc0 >> 3. While in Edit, do a FileSaveAs with the name x.abc >> 4. Exit Edit >> >> Both x.abc0 and x.abc exist, so it is not a Win 95 problem. > >This just means that Edit (whatever that is) works around this bug. >Emacs compiled with DJGPP v2.01 also works in the above way on Windows >95, but that doesn't imply that the bug doesn't exist, just that the >application was smart enough to get its thing right, the bug >notwithstanding. > > sons why, Yesterday starts tommorow, tommorow starts today, The problems always seem to be we're picking up the pieces on the ricochet /\/\/\/\/\/\/\/\/\/\ http://ananke.amu.edu.pl/~grendel \/\/\/\/\/\/\/\/\/