1[e-mail excerpt from Dave Lovelace explaining AOS/VS port, compiler, etc.] 2 3> From: Dave Lovelace <davel@cyberspace.org> 4> Subject: Re: zip on Data General AOS/VS 5> Date: Wed, 17 May 1995 11:02:03 -0400 (EDT) 6> 7> The diffs for zip & unzip are both in the same file. I've also included the 8> extra source files which I wrote, the CLI macros which I used to compile 9> & link the things, & my own history of what I did. Note that some of the 10> changes I made reversed earlier changes, & this was written for my own 11> use (or for others here if I leave or die or something). I hope it will help. 12> 13> This was compiled using DG's C compiler for AOS/VS, rev 4.10. It has been 14> compiled only on an MV-5500 running AOS/VS rev 7.70, but the resulting 15> programs have been distributed & run on several different MVs running various 16> versions of AOS/VS, so it should be fairly independent of at least minor rev 17> variations. To the best of my knowledge it has *not* been tested under 18> AOS/VS II, & I really don't know anything about that environment; possibly 19> the special AOS/VS file info I'm storing in the extra field will have some 20> different format there. 21 22 23 24[README/history info from Dave Lovelace] 25 26In modifying this for use on AOS/VS, I found only a few changes 27were needed for DG C 4.10: 28 292. There was a bug in the inflate() code, because memset() 30 was being called with a non-char pointer. Pretty obviously 31 the other systems where this was used do not have char pointers 32 different from other pointers. IT IS QUITE POSSIBLE THAT OTHER 33 BUGS OF THIS SORT EXIST. Testing did not uncover any. 343. In fileio.c, it appears that utime() is being called correctly, 35 but it does not set the file's time and always returns failure. 36 Since the AOS/VS tar and cpio programs provided by DG also suffer 37 from the fault of not setting file times, I must conclude that 38 this is by design. At any rate, I modified the code (with 39 compilation conditional on a macro AOS_VS) to not say "error" 40 when this occurs. 41 42One change which I think would be desirable: if the filename isn't 43already a relative or absolute pathname (specifying a unique location), 44the program follows the searchlist under AOS/VS. It will unexpectedly 45replace files anywhere in your searchlist. (If you don't use the 46-o option, it will ask you first, but not tell you where the file 47to be replaced resides.) I suspect this could be handled by prepending 48./ to any filenames which don't already begin with /. (I haven't 49checked how this would work inside the program. Possibly this 50could be done in every case - I don't think PKZIP ever stores an 51absolute pathname.) 52 53To see the compile options I used, look at the file MAKE.AOS_VS.CLI 54You may of course need to change the searchlist to use that macro. 55 56 ------------------------------------------------------------------ 5715-dec-93 58I fixed some of the above things, introducing new problems. It now 59won't follow the searchlist - but the logic prevents it from creating 60directories (if they aren't explicitly in the ZIP, anyway). But 61UNZIP now sets the creation time to the time stored in the ZIP, and 62ZIP now stores that instead of the TLM. I had to introduce an 63extra module, with some code of my own and some other public domain 64code, to accomplish this. 65 66 ------------------------------------------------------------------ 67 1-jun-94 68I found an additional bug: the header was causing void to be #define'd 69as int, and prototypes weren't being used. I changed UNZIP.H and 70added a define of PROTO to the MAKE.AOS_VS.CLI and REMAKE.CLI macros. 71 72I found and fixed the bug that prevented the (creation) times from 73being set on files with explicit paths. (The Unix-style paths didn't 74work as inputs to the AOS/VS ?CREATE system call.) 75 76Additional known bugs: 77 781. I have not yet located the source of the bug that prevents the 79 date/time from being set (also ACLs etc.) when an existing file 80 is overwritten. For some reason the call to delete & recreate 81 the file is not being reached. 82 832. We need to do something in ZIP to store (as comments?) the file's 84 type and ACL, and then here in UNZIP extract these and apply 85 them. This is not going to be trivial to make foolproof, but 86 it's badly needed. 87 88 ------------------------------------------------------------------ 89 2-jun-94 90I fixed #1 above. The compiler was checking whether UNIX was defined, 91and it wasn't. It appears that *some* of the places UNIX is used are 92things we can't get along with, so I changed the code to check for 93AOS_VS as well. It seems to work just fine. 94 95I also introduced a function zvs_credir() to create a directory 96(as opposed to a CPD, though it can create CPDs to with the proper 97file-type parameter). Directories in a path which are being created 98will now be directories instead of CPDs. 99 100The big change that's needed now is to have ZIP store (somehow) 101the file's ACL and file type, and then to have UNZIP use this 102information to recreate the file as it was before ZIPping. Ideally, 103ZIP should also store links and CPD max-block info as well. Planned 104strategy: either in the name field but after the name, or in a comment, 105store the packet returned by ?FSTAT (using sys_fstat()), and then 106use this packet for the ?CREATE call in zvs_create(). 107 108 ------------------------------------------------------------------ 10922-Jul-94 110The changes to use the extra-field field for AOS/VS file info are in 111place. In general, if a ZIPfile was created with the current rev of 112ZIP.PR, the files should be restored with file type, ACL, etc. OK. 113I didn't test to make sure element size & max index levels come 114through OK, but I think they should. 115 116Unix symbolic links are now UNZIPped OK, but ZIP.PR isn't yet able 117to ZIP links. When it is, UNZIP should be ready. 118 119In general UNZIP now ignores the searchlist fairly well, but not 120perfectly. If the directory of a file you're UNZIPping can be 121referenced elsewhere in the searchlist, UNZIP will find the file 122there. (For example, if the file UDD/BBASIC/ZZPGSUBSET.SR is in 123the ZIPfile, and : is in your searchlist, then UDD and UDD:BBASIC 124will be created under your current directory, but UNZIP will still 125find :UDD:BBASIC:ZZPGSUBSET.SR instead of =UDD:BBASIC:ZZPGSUBSET.SR. 126 127Filenames (which are now stored in uppercase by ZIP.PR) must be 128matched exactly if specified. This applies to Unix path structure 129as well as case. 130 131 ------------------------------------------------------------------ 132 4-Aug-94 133I fixed a bug which caused (for links only) the Unix pathname to 134be put through ux_to_vs_name twice. The result was that a path 135such as dir1/dir2/fname went first to :dir1:dir2:fname and 136then to dir1?dir2?fname. 137 138I also added the /NOSEA switch to the cc/link lines in the macros 139MAKE.AOS_VS.CLI and REMAKE.CLI. This should prevent any confusion 140over whether a file exists somewhere other than relative to the current 141dir. This would disable calls to system() from using the searchlist, 142but in this program I think they're all useless & hopefully inactive 143anyway. 144 145 ------------------------------------------------------------------ 146