Mail Archives: djgpp-workers/2001/12/26/12:27:10
> Date: Wed, 26 Dec 2001 10:18:16 -0500
> From: DJ Delorie <dj AT delorie DOT com>
>
> What's the best way to tell djgpp programs that *one* drive supports
> LFNs and the others don't?
DJGPP doesn't cope well with this situation.
First, _use_lfn was at one point written to cache the last drive for
which the filesystem was queried about LFN support, but what
eventually went into v2.03 effectively disables that feature. So the
current code reuses the last result (eithe LFN or non-LFN) as long as
the environment variables didn't change. Depending on which drive
did the first _use_lfn call happen, you have a 50-50 chance of doing
TRT ot TWT...
In addition, _use_lfn is used for 2 similar, but not identical
purposes: (1) to know whether the LFN API is supported, and (2) to
know whether the filesystem can store long file names. If these two
don't go together, some library functions might not work as we want
them to.
> The TSR I'm working on doesn't support
> changing drives at the command.com prompt (command.com doesn't use the
> "published" API), so I have to do it inside bash, so bash has already
> checked the "default" non-lfn drive.
I admit I don't understand how does this affect your LFN support.
Could you elaborate?
> It also seems to try the LFN api
> over and over again, even after checking and seeing that LFNs aren't
> supported, depending on how I tell it that the default drive doesn't
> support LFNs.
I think you need to ``play by the rules'' to avoid repeated calls.
_use_lfn expects systems that don't support LFN to return 7100h in the
AX register from the call to function 71A0h. If you fail that call
with anything else, like just the carry, it will think the call
failed because of some transient reason, like invalid drive letter,
and will continue trying on every file-oriented function call.
Also, UNC file names always force a call to 71A0h, because we don't
know what drive do they map to.
> And is it safe to tell djgpp that a drive is case sensitive and case
> preserving, or do we assume otherwise?
I don't think any of the library functions look at these flags. Even
_preserve_fncase doesn't look at the case-sensitive flag (which might
be a bug). If the LFN API is supported, we always try to behave as
if case is important. So I think you won't see any trouble if you
set those flags.
- Raw text -