Mail Archives: djgpp/1998/08/26/01:29:50
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"
> <george DOT foot AT merton DOT oxford DOT ac DOT uk> 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
- Raw text -