view release on metacpan or  search on metacpan

unzip-6.0/aosvs/README  view on Meta::CPAN

replace files anywhere in your searchlist.  (If you don't use the
-o option, it will ask you first, but not tell you where the file
to be replaced resides.)  I suspect this could be handled by prepending
./ to any filenames which don't already begin with /.  (I haven't
checked how this would work inside the program.  Possibly this
could be done in every case - I don't think PKZIP ever stores an
absolute pathname.)

To see the compile options I used, look at the file MAKE.AOS_VS.CLI
You may of course need to change the searchlist to use that macro.

 ------------------------------------------------------------------
15-dec-93
I fixed some of the above things, introducing new problems.  It now
won't follow the searchlist - but the logic prevents it from creating
directories (if they aren't explicitly in the ZIP, anyway).  But
UNZIP now sets the creation time to the time stored in the ZIP, and
ZIP now stores that instead of the TLM.  I had to introduce an
extra module, with some code of my own and some other public domain
code, to accomplish this.

 ------------------------------------------------------------------
 1-jun-94
I found an additional bug: the header was causing void to be #define'd
as int, and prototypes weren't being used.  I changed UNZIP.H and
added a define of PROTO to the MAKE.AOS_VS.CLI and REMAKE.CLI macros.

I found and fixed the bug that prevented the (creation) times from
being set on files with explicit paths.  (The Unix-style paths didn't
work as inputs to the AOS/VS ?CREATE system call.)

Additional known bugs:

1. I have not yet located the source of the bug that prevents the
   date/time from being set (also ACLs etc.) when an existing file
   is overwritten.  For some reason the call to delete & recreate
   the file is not being reached.

2. We need to do something in ZIP to store (as comments?) the file's
   type and ACL, and then here in UNZIP extract these and apply
   them.  This is not going to be trivial to make foolproof, but
   it's badly needed.

 ------------------------------------------------------------------
 2-jun-94
I fixed #1 above.  The compiler was checking whether UNIX was defined,
and it wasn't.  It appears that *some* of the places UNIX is used are
things we can't get along with, so I changed the code to check for
AOS_VS as well.  It seems to work just fine.

I also introduced a function zvs_credir() to create a directory
(as opposed to a CPD, though it can create CPDs to with the proper
file-type parameter).  Directories in a path which are being created
will now be directories instead of CPDs.

The big change that's needed now is to have ZIP store (somehow)
the file's ACL and file type, and then to have UNZIP use this
information to recreate the file as it was before ZIPping.  Ideally,
ZIP should also store links and CPD max-block info as well.  Planned
strategy: either in the name field but after the name, or in a comment,
store the packet returned by ?FSTAT (using sys_fstat()), and then
use this packet for the ?CREATE call in zvs_create().

 ------------------------------------------------------------------
22-Jul-94
The changes to use the extra-field field for AOS/VS file info are in
place.  In general, if a ZIPfile was created with the current rev of
ZIP.PR, the files should be restored with file type, ACL, etc. OK.
I didn't test to make sure element size & max index levels come
through OK, but I think they should.

Unix symbolic links are now UNZIPped OK, but ZIP.PR isn't yet able
to ZIP links.  When it is, UNZIP should be ready.

In general UNZIP now ignores the searchlist fairly well, but not
perfectly.  If the directory of a file you're UNZIPping can be
referenced elsewhere in the searchlist, UNZIP will find the file
there.  (For example, if the file UDD/BBASIC/ZZPGSUBSET.SR is in
the ZIPfile, and : is in your searchlist, then UDD and UDD:BBASIC
will be created under your current directory, but UNZIP will still
find :UDD:BBASIC:ZZPGSUBSET.SR instead of =UDD:BBASIC:ZZPGSUBSET.SR.

Filenames (which are now stored in uppercase by ZIP.PR) must be
matched exactly if specified.  This applies to Unix path structure
as well as case.

 ------------------------------------------------------------------
 4-Aug-94
I fixed a bug which caused (for links only) the Unix pathname to
be put through ux_to_vs_name twice.  The result was that a path
such as    dir1/dir2/fname    went first to    :dir1:dir2:fname    and
then to    dir1?dir2?fname.

I also added the /NOSEA switch to the cc/link lines in the macros
MAKE.AOS_VS.CLI and REMAKE.CLI.  This should prevent any confusion
over whether a file exists somewhere other than relative to the current
dir.  This would disable calls to system() from using the searchlist,
but in this program I think they're all useless & hopefully inactive
anyway.

 ------------------------------------------------------------------