Mail Archives: djgpp/1997/02/05/10:25:51
On 3 Feb 1997, Robert Babcock wrote:
> The documentation for _use_lfn says
>
> "Note that on Windows 95 you don't need to distinguish
> between different drives: they all support LFN API."
>
> This isn't quite true. For example, I find that when running a program over
> a peer-to-peer link from an OS/2 FAT disk, _use_lfn(0) returns 0. I haven't
> tested, but I wouldn't be surprised to find the same behavior with a Netware
> disk which does not have the long namespace installed.
This area is in sore need of information and user experience reports;
only based on such real-world data can the DJGPP LFN support be made
better than it is currently. The information in the libc docs and the
overall design of the LFN support by the low-level library functions
(which automatically turn LFN on when they detect that the OS supports
the LFN API) was based on the assumption that LFN is supported by all
drives. This is always true for local drives; for networked drives, the
assumption was that on Windows 9x everybody would turn the long namespace
on (there's no sense in losing such a goodie by deliberately turning it
off, is there?). If the peer-to-peer link to an OS/2 drive doesn't
support long names (another act of IBM/Microsoft war?), then that's too
bad, but I am not sure this is grave enough cause to change the current
design. There's still plenty of space for work-arounds (see below),
whereas a radical change in the design might break LFN support in other
cases.
> It seems that I can fix the problem by making an early call to
> _use_lfn("c:\\");.
That is indeed a work-around that I suggest in your case. But please be
aware that you generally cannot be 100% sure that c:/ is the boot drive,
or even a local drive. There is an Int 21h function that will tell you
which drive the machine was bootstrapped from, but even that is not always
enough to decide whether _use_lfn("x:/"), where X: is the boot drive, will
tell you whether the LFN API is supported by the OS. The only solution
that is probably more robust would be to make `_use_lfn' (or `_USE_LFN')
loop on all the drives in sight, and see if at least one of them supports
LFN. But IMHO this would punish most of Windows 9x users too much, which
is why the current version of DJGPP libc have chosen to ignore the issue
and boldly assume that all drives support LFN in the same way.
Personally, I am amazed how well the LFN features in v2.01 work (judging
by the apparent lack of complains). Given the patchy and half-hearted
way that it is implemented by Windows 95, you would be surprised how many
compromises such as the one you've just uncovered were necessary when the
LFN support was built into DJGPP library. The problem with mixing LFN and
non-LFN drives is but a tip of an iceberg. (Discovering the rest is left
as an excercise for the interested reader ;-)
- Raw text -