Mail Archives: djgpp-workers/2001/04/27/15:20:12
> You are right for the case of files whose letter-case survives until
> it gets to zip's application code, but this is a different situation.
> File names such as TODO and NEWS are downcased by readdir (unless
> FNCASE is set), because they fit into DOS 8+3 limits, so zip doesn't
> know that they are in upper case. That's what the two possible
> solutions above are trying to avoid: the first stops downcasing in
> readdir, the second avoids calling readdir in the first place.
Hmm.
$ md foo
$ cd foo
$ touch LONG_UPPERCASE
$ touch README
$ ls
LONG_UPPERCASE README
$ zip -9 foo.zip *
adding: LONG_UPPERCASE (stored 0%)
adding: README (stored 0%)
$ zipinfo foo.zip
Archive: foo.zip 250 bytes 2 files
-rw-a-- 2.3 fat 0 tx stor 27-Apr-01 21:17 LONG_UPPERCASE
-rw-a-- 2.3 fat 0 tx stor 27-Apr-01 21:17 README
2 files, 0 bytes uncompressed, 0 bytes compressed: 0.0%
$zip -v
Copyright (C) 1990-1999 Info-ZIP
Type 'zip "-L"' for software license.
This is Zip 2.3 (November 29th 1999), by Info-ZIP.
Currently maintained by Onno van der Linden. Please send bug reports to
the authors at Zip-Bugs AT lists DOT wku DOT edu; see README for details.
Latest sources and executables are at ftp://ftp.cdrom.com/pub/infozip, as of
above date; see http://www.cdrom.com/pub/infozip/Zip.html for other sites.
Compiled with djgpp v2.03 / gcc 2.95.2 19991024 (release) for
MS-DOS (32-bit) on Jun 8 2000.
Zip special compilation options:
ASM_CRC
ASMV
USE_EF_UT_TIME
[encryption, version 2.9 of 22 April 2000]
Zip environment options:
ZIP: [none]
ZIPOPT: [none]
TMPDIR: C:\Windows\Temp
Guess I was wrong about the date; I last built zip a year ago; but the
uppercase handling is in. I'm pretty sure it's part of the standard distro,
though it _might_ be a local patch. Will update my zip sources (there's
probably a new version by now) and check this weekend.
> > This is a bfd problem; it still uses a fixed-size stub area, so
> stubs that
> > aren't exactly as long as the standard stub used by bfd won't work. IIRC
> > this would be hard to fix, as most bfd routines expect to find
> the header
> > info (the coff header, for DJGPP executables) at the start of an object.
>
> Then perhaps we need to define a couple of new targets:
> coff-go32-cwsdstub and coff-go32-pmodestub.
>
> However, I wonder: does this mean that none of the Binutils programs
> will work with these stubs? Will `nm' and `strings' fail, for
> example?
I believe so. I know for a fact that gdb won't work with programs using
nonstandard stubs.
- Raw text -