Mail Archives: djgpp-workers/2001/08/17/06:11:29
> ----------
> Od: sandmann AT clio DOT rice DOT edu[SMTP:sandmann AT clio DOT rice DOT edu]
> Odpowiedz do: djgpp-workers AT delorie DOT com
> Wysłano: 16 sierpnia 2001 16:18
> Do: eliz AT is DOT elta DOT co DOT il
> DW: djgpp-workers AT delorie DOT com; acottrel AT ihug DOT com DOT au
> Temat: Re: Better _open.c, test program
>
> > 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.
>
the old long filename is said by some Microsoft docs to be remembered by the
operating system for a 30 seconds or so even if the file is deleted so that
if you create it later (within these 30 seconds) using the file's short
filename then its longfilename reappers too. This feature is used by the
LFN driver
There may be problems with filename case however, (ie old name foo.c, new
name FOO.C)
Did you see this ?
> I also tested the new _open code on Windows NT 4.0 with the LFN TSR and
> all seems OK.
>
Where could I find the 'last' version of open.c ?
- Raw text -