From:	babcock AT shell1 DOT cybercom DOT net (Robert Babcock)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Error in _use_lfn documentation
Date:	5 Feb 1997 21:39:11 -0500
Organization:	A poorly-installed InterNetNews site
Lines:	33
Message-ID:	<babcock.855195336@cybercom.net>
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 970205163255 DOT 2719A-100000 AT is>
NNTP-Posting-Host:	shell1.cybercom.net
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> writes:

>If the peer-to-peer link to an OS/2 drive doesn't support long names
>(another act of IBM/Microsoft war?), then that's too bad, but I am not sure
>this is grave enough cause to change the current design.

I just tested, and found reasonable behavior: if I run _use_lfn() (from Win95
over a peer-to-peer link) on an OS/2 FAT disk, it says LFN not supported.  If
I test an HPFS disk, it says LFN is supported (and I really can see the long
names).  So I think it does correctly report whether LFN's are supported on
the drive.  I would suggest a small rewording of the documentation from:

"Note that on Windows 95 you don't need to distinguish between different
drives: they all support LFN API."

To:
Note that on Windows 95 you don't need to distinguish between different local
drives: they all support LFN API.  Network drives may or may not support LFN
API.

>> It seems that I can fix the problem by making an early call to 
>> _use_lfn("c:\\");.

>That is indeed a work-around that I suggest in your case.  But please be
>aware that you generally cannot be 100% sure that c:/ is the boot drive,
>or even a local drive.

For now, I'll assume that if C: is not a local drive, you deserve whatever
happens to you.  It doesn't seem to hurt anything to make LFN calls from
Win95 to a drive which doesn't support LFN.

Now, I wonder what happens with Netware drives when the long namespace is
installed...

- Raw text -