home *** CD-ROM | disk | FTP | other *** search
/ Oakland CPM Archive / oakcpm.iso / cpm / cpm68k / arc68k.arc / README < prev    next >
Encoding:
Text File  |  1987-11-27  |  4.0 KB  |  103 lines
  1.  
  2.  
  3. Unix System V ARC Version 1.1
  4.  
  5.  
  6. This is a COMPLETE (I hope!) version of PC ARC v5.12, ported to System V.
  7. It contains as much of the functionality of PC ARC as I could incorporate,
  8. and fixes all known bugs.
  9.  
  10. Version 1.1 is based on the version posted to the net by Mike Stump,
  11. with several fixes and enhancements, as well as some general clean-up.
  12.  
  13. Some enhancements:
  14.  
  15.         Timestamping - arc will now stamp file upon extraction with the
  16.         date and time contained in the header.  This feature may cause
  17.         some discomfort with the recent change in Daylight Savings Time.
  18.  
  19.  
  20.         Full wildcard/pattern matching - arc will take over for the shell
  21.         if it receives standard shell-type wildcards and/or patterns.
  22.         Remember, though, that the shell will always try to expand what
  23.         it can FIRST, so if you explicitly want arc to do expansion,
  24.         quote the arguments.  Also, arc will NOT search for real files
  25.         based on wildcard matches.  I have left that under shell control;
  26.         i.e., typing:
  27.  
  28.                         arc -v "*.c"<RETURN>
  29.  
  30.         will work whether or not real files exist that match the pattern,
  31.         but typing:
  32.  
  33.                         arc -a "*.c"<RETURN>
  34.  
  35.         will report that file '*.c' was not found.
  36.  
  37.  
  38.         14 character file name entries - by default arc now supports
  39.         full 14 character file names in its entries.  This will, however,
  40.         cause the archive to be incompatible with PC ARC, so I have
  41.         added an option ('i') to truncate file names to the standard
  42.         PC limit of 12 characters.  Archives created with this option are
  43.         FULLY compatible with PC ARC.
  44.  
  45.  
  46. Some Bug Fixes:
  47.  
  48.         An archive will no longer try to archive itself, even if it is
  49.         explicitly requested from the command line.  However, an archive
  50.         with a similar name, but in a different directory, can be added.
  51.  
  52.         Arguments passed to arc are now sorted, eliminating the
  53.         possibility of duplicate entries for the same file in an archive.
  54.         The arguments are also checked for duplicates, so it is impossible
  55.         to add the same file name from multiple directories.  Only the
  56.         first occurence is used.
  57.  
  58.         Arc will not core dump if any of the file name arguments cannot
  59.         be found.
  60.  
  61.         Arc now cleans up after itself if it is aborted early.  Also,
  62.         no damage will be done to the archive if arc is aborted.
  63.  
  64.  
  65. Cleanup:
  66.  
  67.         I tried my best to make the code uniform, removed some unused
  68.         variables and functions, and added/changed some of the comments.
  69.  
  70.         I ran the resulting code through lint, which still considers
  71.         the code somewhat inconsistent, but otherwise acceptible,
  72.         with the exception of 'arclzw.c'.  Oh well, we can only do
  73.         so much...
  74.  
  75.  
  76. Known limitations:
  77.  
  78.         Ther is a REMOTE possibility that an archive can become corrupted
  79.         if the IBM(TM) PC compatibility option ('i') is used/not used when it
  80.         should/shouldn't be.  This only happened to me once out of 150+
  81.         archives, and even that was during the early stages of the cleanup.
  82.         As a rule, if I can't remember whether or not the 'i' option was
  83.         used, I simply test the archive in questoion.  Testing an archive
  84.         can do NO damage to it.
  85.  
  86.  
  87. This code has been thoroughly (if there is such a thing) tested on an
  88. AT&T 3B5, 3B15, 3B2/300, and 3B2/400, running SYS V release 2 and release 3.
  89.  
  90. I tried to keep things fairly portable, though I am not that familiar with
  91. BSD.  I imagine that most things should work (I did change all the 'rindex'
  92. calls to 'strrchr', sorry BSD), but I imagine that the setstamp() function
  93. is fairly System V dependent.  In any event, I will cheerfully listen to
  94. any reports of bugs and/or fixes, and will try to maintain the code as well
  95. as I can.
  96.  
  97. Chris Seaman
  98. {ihnp4, rtech}!cpsc6a!crs
  99.  
  100. de as well
  101. as I can.
  102.  
  103. Chr