Message-ID: <B0000082602@stargate.astr.lu.lv>
From: "Andris Pavenis" <pavenis AT lanet DOT lv>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp-workers AT delorie DOT com
Date: Thu, 8 Apr 1999 21:42:47 +0300
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: LFN=y and MS-RAMDRIVE
References: <199904081648 DOT SAA12220 AT father DOT ludd DOT luth DOT se>
In-reply-to: <Pine.SUN.3.91.990408185010.27027O@is>
X-mailer: Pegasus Mail for Win32 (v3.02b14)
Reply-To: djgpp-workers AT delorie DOT com

On 8 Apr 99, at 18:56, Eli Zaretskii wrote:

> 
> On Thu, 8 Apr 1999, Martin Str|mberg wrote:
> 
> > According to Eli Zaretskii:
> > > What does ``_use_lfn ("g:/")'' return?
> [snip]
> > says
> > 
> > "0.
> > "
> 
> Yep, it seems the MS RAM drive doesn't support long file names.  I'd bet 
> they simply didn't want to work on the driver to make it LFN-aware.  What 
> a joke!

At least it is no so for Win95 OSR2. With MS RAMDRIVE.SYS I'm getting
output 1 from the same test and I haven't saw any LFN related problems with it.
So perhaps it's Win98 related problem.

Andris


> You should be able to change the sources of `sort' to make it call 
> _use_lfn on the temp file prefix, instead of using _USE_LFN.  
> 
> But personally, I won't recommend using that RAM drive at all, since many
> other programs will probably fail in ``interesting'' ways.  DJGPP does not
> live well with systems where some drives support LFN while others don't,
> since too many library functions call _USE_LFN, and the logic inside
> _use_lfn that caches the last drive it was called with isn't perfect... 
>