Date: Thu, 27 Aug 1998 14:34:19 +0300 (IDT) From: Eli Zaretskii To: George Foot cc: sl AT psycode DOT com, djgpp AT delorie DOT com Subject: Re: RHIDE Problems (C++ Headers) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Wed, 26 Aug 1998, George Foot wrote: > 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. More accurate: LFN=y *does not disable* LFN support. It is the same as not definining LFN at all, but at least in v2.01 it is safer to define it to Y explicitly (it's a long story). In v2.02, either not defining it or defining it to Y should have the same effect. > 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". Correct. > 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. Actually, I don't recommend to ``not want long filenames''. Using DOS unzip programs and setting LFN=n is only a tip of an iceberg: problems will start cropping since non-DJGPP programs don't know about LFN. In particular, COMMAND.COM still uses long names. So you will be in trouble if you want to stick to short names. The next release of the FAQ will include a section on how to set up such cases, but it's not for the faint of heart. Fortunately, I don't expect that too many people would like to disable LFN support on Windows 9X.