Mail Archives: djgpp-workers/2001/12/26/13:17:32
> I admit I don't understand how does this affect your LFN support.
> Could you elaborate?
The first drive checked is *always* the non-lfn one, because I can't
change to that drive before starting bash (or other djgpp programs).
So I can't even say "well, start with the lfn one and just never use
the others, and we'll get by."
> 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.
So it seems that for the non-lfn drives, I need to emulate the lfn
api, at least in a dumb way (by calling the non-lfn api in its place).
> 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.
Ok. I'm mapping a linux ext3 filesystem, so I'd rather avoid all the
case conversion stuff.
- Raw text -