Date: Sat, 31 Oct 1998 09:20:48 +0000 (GMT) From: George Foot To: djgpp AT delorie DOT com Subject: Re: C++ with DJGPP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com On Fri, 30 Oct 1998, Mike Ruskai wrote: > >It works on a completely non-LFN system (MS-DOS < 7): when opening > >"streambuf.h", the extra character is dropped and you get "streambu.h". > >Since the same thing happened when unzipping, it's found. Try it and > >see. > > The same thing did *not* happen when unzipping for me, and for the person who > began this thread. > > The basic point here is that the package relies on identical conditions when > unarchiving and compiling. This presents a problem for individuals like > myself who habitually use a native interface for manipulating files > (including archives), and for any individual who may wish to involve a > network that makes using long filenames impossible. Please read the FAQ section that describes how to turn off NameNumericTail. > >On an LFN system where LFNs are enabled, it also works, provided the > >long name was used in creating the file. I think we've established > >that. > > > >The cases that don't work are: > >1. LFN platform/LFN's disabled in DJGPP/File created with Winzip or > >similar/NameNumericTail=1 > >2. LFN platform/LFN's enabled in DJGPP/File created with PKUNZIP > > > >1 will go away when LFN=Y is the default, and 2 seems empirically to be > >very uncommon. Most newbies use Winzip. > > 3. LFN platform/no LFN in DOS mode/file unzipped natively. Turning off NameNumericTail should solve this. > 4. LFN installation system/non-LFN system on network. It could also solve this; it depends how exactly the network filesystem is non-LFN when Windows itself does support LFN. > That's just what I can think of off hand. I don't doubt that my imagination > has missed many circumstances where failure would result. I think turning off NameNumericTail should solve the problem in pretty much all circumstances, since it's basically always the same problem. > >OTOH, I believe Eli's point is well made that much of this complexity > >will soon be unneeded, when LFN=Y. People who want or need to use > >Windows without LFNs can find, with minimal RTFM'ing, that PKUNZIP will > >solve their problems. Same goes for OS/2 and so on. > > I disagree on the "solution" chosen, but it's not my show. > > FWIW, I never found anything in any documentation indicating that the archive > was packaged in such a way as to make these problems possible. It may very > well be in the documentation somewhere, but it would take less time to figure > the problem out than find it, if my experience is any indication. But what do you want? Since djgpp supports long filenames in the most common circumstances, the distributions must use those long filenames. If the distributions used short filenames, everything would break on LFN systems, which, to be honest, are probably more common these days. If you turn off NameNumericTail you get the same truncation rules for the short version of the filename as you do in normal DOS calls, so djgpp without LFN will read the file by its short name and djgpp with LFN will read it by its long name. I have no idea what sort of solution applies to your network driver problem really, since I am getting the impression that the network driver doesn't let you use long filenames. If they get nicely truncated DOS-style, djgpp will be able to read them provided you turned off NameNumericTail. -- george DOT foot AT merton DOT oxford DOT ac DOT uk xu do tavla fo la lojban -- http://xiron.pc.helsinki.fi/lojban/lojban.html