home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 9 Archive / 09-Archive.zip / unzip531.zip / aosvs / README < prev   
INI File  |  1996-04-26  |  7KB  |  146 lines
  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.  
  26. In modifying this for use on AOS/VS, I found only a few changes
  27. were needed for DG C 4.10:
  28.  
  29. 2. 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.
  34. 3. 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.  
  42. One change which I think would be desirable: if the filename isn't
  43. already a relative or absolute pathname (specifying a unique location),
  44. the program follows the searchlist under AOS/VS.  It will unexpectedly
  45. replace 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
  47. to be replaced resides.)  I suspect this could be handled by prepending
  48. ./ to any filenames which don't already begin with /.  (I haven't
  49. checked how this would work inside the program.  Possibly this
  50. could be done in every case - I don't think PKZIP ever stores an
  51. absolute pathname.)
  52.  
  53. To see the compile options I used, look at the file MAKE.AOS_VS.CLI
  54. You may of course need to change the searchlist to use that macro.
  55.  
  56.  ------------------------------------------------------------------
  57. 15-dec-93
  58. I fixed some of the above things, introducing new problems.  It now
  59. won't follow the searchlist - but the logic prevents it from creating
  60. directories (if they aren't explicitly in the ZIP, anyway).  But
  61. UNZIP now sets the creation time to the time stored in the ZIP, and
  62. ZIP now stores that instead of the TLM.  I had to introduce an
  63. extra module, with some code of my own and some other public domain
  64. code, to accomplish this.
  65.  
  66.  ------------------------------------------------------------------
  67.  1-jun-94
  68. I found an additional bug: the header was causing void to be #define'd
  69. as int, and prototypes weren't being used.  I changed UNZIP.H and
  70. added a define of PROTO to the MAKE.AOS_VS.CLI and REMAKE.CLI macros.
  71.  
  72. I found and fixed the bug that prevented the (creation) times from
  73. being set on files with explicit paths.  (The Unix-style paths didn't
  74. work as inputs to the AOS/VS ?CREATE system call.)  
  75.  
  76. Additional known bugs:
  77.  
  78. 1. 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.  
  83. 2. 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
  90. I fixed #1 above.  The compiler was checking whether UNIX was defined,
  91. and it wasn't.  It appears that *some* of the places UNIX is used are
  92. things we can't get along with, so I changed the code to check for
  93. AOS_VS as well.  It seems to work just fine.
  94.  
  95. I 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
  97. file-type parameter).  Directories in a path which are being created
  98. will now be directories instead of CPDs.
  99.  
  100. The big change that's needed now is to have ZIP store (somehow)
  101. the file's ACL and file type, and then to have UNZIP use this
  102. information to recreate the file as it was before ZIPping.  Ideally,
  103. ZIP should also store links and CPD max-block info as well.  Planned
  104. strategy: either in the name field but after the name, or in a comment,
  105. store the packet returned by ?FSTAT (using sys_fstat()), and then
  106. use this packet for the ?CREATE call in zvs_create().
  107.  
  108.  ------------------------------------------------------------------
  109. 22-Jul-94
  110. The changes to use the extra-field field for AOS/VS file info are in
  111. place.  In general, if a ZIPfile was created with the current rev of
  112. ZIP.PR, the files should be restored with file type, ACL, etc. OK.
  113. I didn't test to make sure element size & max index levels come
  114. through OK, but I think they should.
  115.  
  116. Unix symbolic links are now UNZIPped OK, but ZIP.PR isn't yet able
  117. to ZIP links.  When it is, UNZIP should be ready.
  118.  
  119. In general UNZIP now ignores the searchlist fairly well, but not
  120. perfectly.  If the directory of a file you're UNZIPping can be
  121. referenced elsewhere in the searchlist, UNZIP will find the file
  122. there.  (For example, if the file UDD/BBASIC/ZZPGSUBSET.SR is in
  123. the ZIPfile, and : is in your searchlist, then UDD and UDD:BBASIC
  124. will be created under your current directory, but UNZIP will still
  125. find :UDD:BBASIC:ZZPGSUBSET.SR instead of =UDD:BBASIC:ZZPGSUBSET.SR.
  126.  
  127. Filenames (which are now stored in uppercase by ZIP.PR) must be
  128. matched exactly if specified.  This applies to Unix path structure
  129. as well as case.
  130.  
  131.  ------------------------------------------------------------------
  132.  4-Aug-94
  133. I fixed a bug which caused (for links only) the Unix pathname to
  134. be put through ux_to_vs_name twice.  The result was that a path
  135. such as    dir1/dir2/fname    went first to    :dir1:dir2:fname    and
  136. then to    dir1?dir2?fname.
  137.  
  138. I also added the /NOSEA switch to the cc/link lines in the macros
  139. MAKE.AOS_VS.CLI and REMAKE.CLI.  This should prevent any confusion
  140. over whether a file exists somewhere other than relative to the current
  141. dir.  This would disable calls to system() from using the searchlist,
  142. but in this program I think they're all useless & hopefully inactive
  143. anyway.
  144.  
  145.  ------------------------------------------------------------------
  146.