X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f Date: Wed, 26 Dec 2001 19:25:08 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: DJ Delorie Message-Id: <3995-Wed26Dec2001192507+0200-eliz@is.elta.co.il> X-Mailer: emacs 21.1.50 (via feedmail 8 I) and Blat ver 1.8.9 CC: djgpp-workers AT delorie DOT com In-reply-to: <200112261518.fBQFIGZ15433@envy.delorie.com> (message from DJ Delorie on Wed, 26 Dec 2001 10:18:16 -0500) Subject: Re: lfn from scratch... References: <200112261518 DOT fBQFIGZ15433 AT envy DOT delorie DOT com> 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 > Date: Wed, 26 Dec 2001 10:18:16 -0500 > From: DJ Delorie > > 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.