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