Mail Archives: djgpp-workers/2001/08/06/14:42:30
> From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
> Date: Mon, 6 Aug 2001 11:54:28 -0500 (CDT)
>
> 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 ...
Right. I expect this strategy to be hard to implement universally.
(Although IIRC that's exactly what ntlfn is doing on NT4; but ntlfn
doesn't have any choice, and it has the Win32 API on its side.)
That's why I think we should try to be pragmatic at first: if the
number of functions that are broken is small, it might be better to
have local work-arounds for those functions only.
> 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.
From what we know now, it sounds like the DOS character devices
emulation is completely broken if you go through LFN functions.
Witness the lack of character-device bit in the attribute byte
returned by findfirst--this has nothing to do with file handles.
That said, you might try some of the subfunctions of function 440Dh,
perhaps they might help.
> 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 ...
It seems Andrew found out that LFN calls used by fstat work on handles
returned by SFN open function.
- Raw text -