From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10108061654.AA19657@clio.rice.edu>
Subject: Windows 2000 LFN issues
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Mon, 6 Aug 2001 11:54:28 -0500 (CDT)
Cc: acottrel AT ihug DOT com DOT au (Andrew Cottrell), djgpp-workers AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.1010806182933.27218C-100000@is> from "Eli Zaretskii" at Aug 06, 2001 06:41:13 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

I thought about always making "open" use the SFN instead of the LFN.
What do we do with creating new LFN files?  Those handles would break
unless something like dup worked.  I would hate to create the file,
close it and re-open with SFN ...

I agree with Eli's earlier suggestion of looking at all the libc calls
and testing them, then developing a strategy.

We could use LFN calls universally on LFN handles where available.
We could convert LFN names to short names and use standard handles.

While the 0x57xx calls seem to be replaceable with LFN calls, I didn't 
immediately see the LFN equivalent for the 0x44xx device attributes calls.

Some features like extended fstat() info would only be available on LFN
handles (unless the LFN call worked on SFN handles...) so we should 
elaborate before construction ...