From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: <djgpp-workers AT delorie DOT com>
Cc: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Subject: RE: ANNOUNCE: Fileutils 4.0 beta 2
Date: Fri, 27 Apr 2001 21:20:52 +0200
Message-ID: <CAEGKOHJKAAFPKOCLHDIGENNCCAA.tim.van.holder@pandora.be>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <9791-Fri27Apr2001203542+0300-eliz@is.elta.co.il>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> 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.