Mail Archives: djgpp-workers/2001/12/26/21:30:15
According to Eli Zaretskii:
> > 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.
For caching, I've a similar code for FAT32. If I can find it. Anyway
for the FAT32 caching ability look in the archives of djggp-workers or
ask me if I can find it.
> > 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).
We could say "if you're out on the net, expect a slowdown".
I think UNC would be a welcome addition to DJGPP. But I seem to recall
that you don't have much time.
Anyway it's probably a 2.04 or later issue.
Right,
MartinS
- Raw text -