Mail Archives: djgpp-workers/2001/12/26/15:10:33
> From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
> Date: Wed, 26 Dec 2001 12:32:09 -0600 (CST)
>
> > > 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.
>
> Should we look at fixing it?
It would be nice, but I'm afraid it will require non-trivial
changes. We should probably have two functions instead of _use_lfn:
one for testing the LFN API support, the other testing whether a
certain disk can store long file names. They both should use some
caching, to be efficient, and library functions should use one or the
other, depending on what they need.
> I always assumed UNCs were not supported at all.
That's about right. As soon as a UNC gets taken apart by library
functions, like to find the drive letter, we fail. If the UNC goes
directly to the system call, it will usually work, at least on
Windows.
> Should we fix this?
It's not clear to me how to fix this. We should either augment those
library functions which tinker with file names to know about UNCs, or
write code to map between a UNC and a drive letter. The latter is
safer, but since the mapping can be changed behind our back (the user
can run "net use" from another DOS box), we cannot cache the mapping,
and will need to compute the drive letter each time, which will slow
down file-related system calls (especially since network-related calls
are slow).
- Raw text -