Date:	Tue, 7 Aug 2001 10:54:26 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc:	Andrew Cottrell <acottrel AT ihug DOT com DOT au>, djgpp-workers AT delorie DOT com
Subject:	Re: Windows 2000 /dev/null permission query
In-Reply-To:	<10108070445.AA12938@clio.rice.edu>
Message-ID:	<Pine.SUN.3.91.1010807105348.6564A-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Mon, 6 Aug 2001, Charles Sandmann wrote:

> > > > Another idea might be to use `dup' to duplicate a handle from an LFN
> > > > open call, then see if that handle has the same problems with function
> > > > 5701 as the original handle.  (Since `dup' doesn't have an LFN analog,
> > > > maybe the duplicated handle is created as a non-LFN one, who knows?)
> 
> >  Not tested. Tomorrow
> 
> Don't bother - dup doesn't help, it continues to fail.

I was afraid of this, sigh...  That was a wild guess anyway.

> I haven't tried creates - I don't know if their LFN handles fail.  If so
> I guess we create LFN/close get short name open short?  Yuk.  Sigh.

However yucky, this might be a solution, but only if we find that SFN
handles don't fail any handle-related calls that are part of the LFN
API.  For example, what about function 71A6h?  (The Microsoft LFN API
document does seem to specify that all LFN handle-related functions
should work for handles created by function 6Ch, so there is hope.)

- Raw text -