To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	InfoZip zip19 fix to -r bug
Date:	Mon, 16 Nov 92 13:26:35 +1000
From:	Cameron Davidson <cjd AT brb DOT dmt DOT csiro DOT au>

I am using zip19 patchlevel 1 with djgpp 1.08 and having the same problems
as reported by  Zachary Heilig. I cannot find a patch 2 around, so cannot
understand how others have reported no problems with djgpp-compiled versions.
The cause of the problem seems to relate to the structure returned by
findfirst/findnext. The DOS-16 structure is hard-coded into fileio.c
however GO32 seems to return a somewhat different structure such that some
internal values are quad-byte aligned. The consequence of this is that 
the start of the name is 2 bytes further on and, at least on the directories
I tried it with, procname() recurses infinitely with a null name.

Here is the diff for fileio.c (in zip19) which seems to fix the problem for me:

*** fileio.c	Mon Nov 16 12:30:43 1992
--- fileio.c_orig	Thu Sep  3 14:32:23 1992
***************
*** 217,230 ****
  #        define FFIRST(n,d)     _dos_findfirst(n,FATTR,(struct find_t *)d)
  #        define FNEXT(d)        _dos_findnext((struct find_t *)d)
  #      endif /* ?__TURBOC__ */
- #      ifdef __GO32__
-        typedef struct direct  {
-          char  d_reserved[28];
-          long  d_fsize;
-          char  d_name[16];
-          short	d_first;
-        } DIR;
- #      else /* ! __GO32__ */
         typedef struct direct {
           char d_reserved[30];
           char d_name[13];
--- 217,222 ----
***************
*** 233,239 ****
  	 HANDLE d_hFindFile;
  #endif
         } DIR;
- #      endif /* ?__GO32__ */
  #     endif /* ?OS2 */
  #    else /* !MSDOS */
  #      ifdef VMS
--- 225,230 ----

Cameron Davidson,
CSIRO Division of Manufacturing Technology,   Telephone: +61 7 212 4535
Qld Centre for Advanced Technologies,         Facsimile: +61 7 212 4681
2643 Moggill Rd, Pinjarra Hills, Qld, 4069.   Internet:  cjd AT brb DOT dmt DOT csiro DOT au

- Raw text -