X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Date: Sun, 30 Dec 2001 13:05:35 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc: djgpp-workers AT delorie DOT com, wojciech DOT galazka AT polkomtel DOT com DOT pl
Subject: Re: lfn from scratch...
In-Reply-To: <10112300432.AA14322@clio.rice.edu>
Message-ID: <Pine.SUN.3.91.1011230130436.10061A-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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


On Sat, 29 Dec 2001, Charles Sandmann wrote:

> > > Either modify or assume that no drive supports LFN API
> > > because the default drive does not support it and libc calls _use_lfn(0) to 
> > > check for LFN API support
> > > Or I'm wrong there ?
> > 
> > Some of the library functions do call _use_lfn with a non-NULL file
> > name argument. 
> 
> My understanding is that we should really have *all* calls to _use_lfn
> in the library be called with the file name we want to operate on
> (or at least the disk letter).

Not necessarily: in most cases, all we want to know is whether the OS
supports the LFN API, to decide which function of Int 21h to call.  If
the LFN API is available, we always prefer it, even if the file name
is short or resides on a filesystem which annot store long names.

The precise level of LFN support for a given disk only matters to use
when we want to know, e.g., whether file names like foo.bar.exe are
possible (see dosexec.c, for example).

Also, we don't always have a file name to prob the LFN support on its
disk.  One example is function 5704h called by utime, another is
function 71A6h called by fstat.

I think we need two separate functions for the two kinds of tests.

> > > > Since this applies to all programs, simply replacing _use_lfn with a
> > > > custom version will do what you want.  So I don't see a reason to
> > > > invent an application-level feature like the one you suggest.
> > > 
> > > It's easier to put a custom version of _use_lfn in a separate library 
> > > than to modify libc itself.
> > 
> > Perhaps; but that, too, does not require any handler, just a
> > replacement in a separate library.
> 
> I don't understand the problem - I think we should fix libc to do the
> right thing instead of expecting an application to hook in and try to
> fix it?

Yes, I agree.  That's what I was trying to say.