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
Content-Type: TEXT/PLAIN; charset=US-ASCII
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
Precedence: bulk


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.)