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: from "Eli Zaretskii" at Aug 16, 2001 02:20:15 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 > 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.