Mail Archives: djgpp/1998/10/31/04:22:39
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
- Raw text -