Date: Wed, 5 Feb 1997 17:01:40 +0200 (IST) From: Eli Zaretskii To: Robert Babcock cc: djgpp AT delorie DOT com Subject: Re: Error in _use_lfn documentation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 ;-)