From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10108161418.AA17247@clio.rice.edu>
Subject:	Re: Better _open.c, test program
To:	eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date:	Thu, 16 Aug 2001 09:18:18 -0500 (CDT)
Cc:	djgpp-workers AT delorie DOT com (DJGPP developers), acottrel AT ihug DOT com DOT au
In-Reply-To:	<Pine.SUN.3.91.1010816141659.12766D-100000@is> from "Eli Zaretskii" at Aug 16, 2001 02:20:15 PM
X-Mailer:	ELM [version 2.5 PL2]
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

> Did you have an opportunity to test whether using SFN open nukes the long 
> file name entry from the directory, e.g. if you use O_TRUNC?  I vaguely 
> remember something about such side effects of using legacy DOS calls.

The example program has an O_TRUNC open call at the end, and I tried it with
a long name and it seemed to keep the old name fine.  I should close the
previous handle to the file in the test to make sure, but I didn't see 
this a a problem.

> Perhaps we should simply add the code to your test program, which would 
> use findfirst or stat after the last open, to see whether the file still 
> exists under the original long name.

I had actually planned to add both the direct findfirst and stat calls to
the test program to record their behavior on the various platforms.

I also tested the new _open code on Windows NT 4.0 with the LFN TSR and
all seems OK.

- Raw text -