Comments: Authenticated sender is From: "George Foot" To: sl AT psycode DOT com Date: Wed, 26 Aug 1998 06:28:10 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: RHIDE Problems (C++ Headers) Reply-to: george DOT foot AT merton DOT oxford DOT ac DOT uk CC: djgpp AT delorie DOT com Message-Id: Precedence: bulk On 26 Aug 98 at 4:12, sl AT psycode DOT com DOT REMOVE_THIS wrote: > On Sun, 23 Aug 1998 23:50:13, "George Foot" > wrote: > > > Yes, that's already been done for v2.02. This will fix nearly all of > > these problems; some will still exist though. I think the original > > reason for defaulting to `n' was that it wasn't known how stable the > > LFN support would be. > > But setting LFN to 'y' makes no real sense.. Not _EVERYONE_ has > access to LFNs.. I run under OS/2 which only supports FAT-16.. OK, more detail: Setting "LFN=y" doesn't force LFNs to be used, it just enables them. If the OS supports them, djgpp will use them; if not, it will stick with 8.3 filenames. However, the problems people report are mainly caused by clashes between types of unzipping tool and djgpp setup. All of these problems will only arise if you use an OS that supports long filenames. If you use a DOS unzip tool that doesn't recreate long filenames (i.e. it truncates them) then you should "set LFN=n" to disable long filenames, at least whenever you use those zips. This way, djgpp's filing functions truncate the names to 8.3 format just as the DOS unzip program did, and everything works fine (provided you don't have clashes in the shortened filenames). If you use an unzip tool that understands long filenames then you must "set LFN=y" so that djgpp programs can see the long filenames created. Otherwise the truncated filenames don't match up and you get missing file problems. Obviously someone who doesn't have access to LFN won't be using an unzip program that understands long filenames. Even though v2.02 will default to LFN=y, long filename support will only be enabled if the OS provides the functions. If you don't have access to LFN in your OS, it won't provide the functions and both your unzip program and djgpp programs will happily use short filenames. The exception to that though is Windows NT; at present djgpp can't access NT's long filenames, because NT does not have the LFN API for DOS boxes. So you must treat it as a short filename system, and use a DOS unzip program. There are compromises in fact; so long as you're prepared to sort out problems as they occur, you can (as I do) use PKUNZIP and still have LFN=y. You just need to be prepared to turn off LFN if you have problems. Another possibility is to rename all the truncated filenames after unzipping something. Tedious... Finally, some programs may have internal bugs which cause them to break on long filenames. An example is RHIDE, which tries to link in the standard C++ library with "-lstdcx" when its real name is "-lstdcxx". RHIDE is assuming that the name should be truncated. If you follow the instructions to change its request to "-lstdcxx" then the truncation (or lack of truncation) will fall down to the djgpp functions and the presence/absence of LFN support. Provided you followed the instructions above, you won't have problems any more. In brief, if you want to avoid all problems then you must decide once and for all whether or not you want to use long filenames. If you do, throw out PKUNZIP and get an unzip program that knows about long filenames, and "set LFN=y". If you don't want long filenames, make sure you use an unzip program like PKUNZIP that doesn't understand long filenames, and "set LFN=n" in your environment. This setting will only have any effect if LFN is supported by your OS; if it's not then you don't have a choice and must go without LFNs. -- george DOT foot AT merton DOT oxford DOT ac DOT uk