home *** CD-ROM | disk | FTP | other *** search
/ Frozen Fish 1: Amiga / FrozenFish-Apr94.iso / bbs / alib / d7xx / d724 / backup.lha / BackUP / BackUP.doc < prev    next >
Text File  |  1992-09-04  |  14KB  |  268 lines
  1. ----------------------------------------------------------------------------
  2. ****************************** Legal Stuff ***************** Aug. 18, 1992 *
  3. ----------------------------------------------------------------------------
  4.  
  5.                        BackUP V3.5 © Felix R. Jeske
  6.  
  7. BackUP is a shareware, freely distributable hard drive backup program for
  8. the Amiga under Workbench 2.0.  If you like BackUP and regularly use it, I
  9. would appreciate being sent a $15 contribution to the following address:
  10.  
  11.                               Felix R. Jeske
  12.                         3746 North Oleander Avenue
  13.                           Chicago, IL  60634-3210
  14.                                     USA
  15.  
  16. Contributors will receive the latest version of BackUP (I am already adding
  17. context sensitive help and a few other goodies) plus a few other programs
  18. I've written but not published.  Contributors of $25 or more will receive
  19. the complete copyrighted source.
  20.  
  21. Suggestions, comments and criticisms (ouch) are also welcome at the above
  22. address.  I am quite proud of BackUP and will gladly support it.
  23.  
  24.                                 DISCLAIMER
  25.  
  26. FELIX R. JESKE MAKES NO WARRANTIES EITHER EXPRESSED OR IMPLIED, WITH
  27. RESPECT TO THIS SOFTWARE, ITS QUALITY, PERFORMANCE OR FITNESS FOR ANY
  28. PARTICULAR PURPOSE.  THIS SOFTWARE IS PROVIDED "AS IS."  THE ENTIRE RISK
  29. AS TO QUALITY AND PERFORMANCE OF THE SOFTWARE IS WITH THE USER.  IN NO
  30. EVENT WILL FELIX R. JESKE BE LIABLE FOR DIRECT, INDIRECT, INCIDENTAL OR
  31. CONSEQUENTIAL DAMAGES RESULTING FROM ANY DEFECT IN THE SOFTWARE.
  32.  
  33. ----------------------------------------------------------------------------
  34. ********************************* Credits **********************************
  35. ----------------------------------------------------------------------------
  36.  
  37. Many thanks go to the developers of ARP who have created an extremely
  38. useful collection of routines in one library and have made it easy to
  39. program as well.
  40.  
  41. Also, thanks go to Holger P. Krekel and Olaf Barthel for use of their
  42. lh.library.  This is an excellent version of the LZH compression algorithm
  43. that, again, is very easy to program.
  44.  
  45. ----------------------------------------------------------------------------
  46. *************************** System Requirements ****************************
  47. ----------------------------------------------------------------------------
  48.  
  49. BackUP requires Workbench 2.0, 1MB of RAM, a hard drive (obviously) and as
  50. many floppy drives as you can afford.  BackUP also requires arp.library V39
  51. (available on FF123, not distributed with BackUP) and lh.library V1
  52. (available on FF436, distributed with BackUP)
  53.  
  54. ----------------------------------------------------------------------------
  55. ***************************** Historical Info ******************************
  56. ----------------------------------------------------------------------------
  57.  
  58. BackUP was initially developed on a A500 under Aztec C 3.6a.  Workbench 2.0
  59. additions were made on a A3000 under Aztec C 5.2a.
  60.  
  61.    V3.5  -  First public release
  62.  
  63.    V3.4  -  Added compression using lh.library
  64.  
  65.    V3.0  -  Discontinued use of req.library and added custom gadgetry
  66.  
  67.    V2.0  -  Added gadgets using req.library
  68.  
  69.    V1.0  -  Added primitive interface using autorequestors and the console
  70.  
  71.    V0.9  -  Initial development of the backup and restore engines
  72.  
  73. I started developing BackUP after my purchase of a $700 (groan) 30MB Supra
  74. hard drive.  Not wanting to spend any more money than I had to, I started
  75. on BackUP after reading about programming the trackdisk.device in an issue
  76. of Transactor for the Amiga by Bob Rakosky (August '89:  Vol. 2, Issue 5).
  77. After figuring out how to do raw reads and writes to the floppy drive, I
  78. learned about parsing a partitions directory structure.  I heard about ARP
  79. in another issue of Transactor and finally got my hands on it.  I
  80. incorporated req.library after buying CygnusEd which uses it quite heavily.
  81. The current version of the code is almost identical to that under
  82. req.library except for cosmetics.  I borrowed the current gadgetry style
  83. from AVS (Application Visualization System), a scientific visualization
  84. package I program and use at work on UNIX workstations.  Finally, I found
  85. lh.library on Fred Fish Disk #436 and included compression as an option.
  86.  
  87. ----------------------------------------------------------------------------
  88. ******************************** Benchmarks ********************************
  89. ----------------------------------------------------------------------------
  90.  
  91. The target machine for BackUP is any Amiga with at least two (2) floppy
  92. drives.  Being restricted to one floppy drive eliminates the continuous
  93. write feature.  BackUP does not support tape drives since I don't have one.
  94. Compression is only recommended for fast machines or if you really want to
  95. save disks (55% compression is typical) as the on-the-fly compression does
  96. slow down the backup.  Compression actually speeds up the restore since the
  97. speed bottleneck is the floppy read/write time.  The decompression process
  98. is so fast that reading in less data, decompressing it in memory and
  99. writing it out to the hard drive is faster than reading and writing out the
  100. original uncompressed data which took longer to load from the floppy.
  101.  
  102. My only real comparison of the capabilities of BackUP to other hard drive
  103. backup programs is my experience with HDBackup (shipped with my A3000) and
  104. other PD backup programs I've uploaded.  Since most of the PD backup
  105. programs I've obtained are CLI based, I only compare BackUP and HDBackup
  106. since the CLI is not well suited to perform such an operation.  Therefore,
  107. the following is a comparison of BackUP and HDBackup working on 294 files
  108. comprising about 1.1MB of data with compression and verify on.  It shows
  109. the following:
  110.  
  111.                          BackUP                        HDBackup
  112.                          ------                        --------
  113.  
  114. Executable Size            30K                            81K
  115.  
  116. Memory Usage              430K                           475K
  117. While Backing
  118.  
  119. Time to Backup            2:56                           4:03
  120.  
  121. Number of Disks             1                              3
  122.  
  123. I could not figure out why HDBackup needed three (3) disks to backup 1.1MB
  124. of data, especially when full compression was enabled.  In uncompressed
  125. form, it should have only occupied two disks.
  126.  
  127. ----------------------------------------------------------------------------
  128. ******************************* User Docs **********************************
  129. ----------------------------------------------------------------------------
  130.  
  131.                                   BACKUP
  132.  
  133. The backup procedure consists of selecting the partition to backup, the
  134. specific directories and files to backup within the partition, selecting
  135. which floppy drives to use during the backup and finally the swapping of
  136. disks in and out of the floppy drives.
  137.  
  138. When BackUP boots up, it polls the machine for all hard drive partitions
  139. and all floppy drives.  A gadget for each is created on the main screen.
  140. The user need only press on one of the labeled partition buttons to start
  141. reading the complete directory contents into memory.  When done, a standard
  142. file requestor displays the entire directory structure.
  143.  
  144. A few methods are available to the user as to how files are selected to be
  145. included in the backup.  The order of the methods chosen is important.  For
  146. example, selecting a particular file in a directory and then deselecting
  147. the entire directory will deselect that file.  The following lists the
  148. order in which the selection process should proceed.
  149.  
  150.    1) The Incremental/Full button changes whether files with their archived
  151.       bits set are included in the selected file list.
  152.  
  153.    2) The Include and Exclude wildcard patterns are convenient ways to
  154.       include/exclude large groups of files.  A file is selected for backup
  155.       if it matches the Include pattern and does NOT match the Exclude
  156.       pattern.  The ARP pattern matching system is used and therefore
  157.       asterisks (*) can be used in place of Commodore's global wildcard (#?).
  158.       Also patterns can be ORed together via the pipe (|) operator to form
  159.       more complex pattern such as:
  160.  
  161.                                 *.(c|h)|a*
  162.  
  163.       which would match all files ending with either a .c or .h extension
  164.       or files beginning with a.
  165.  
  166.    3) Whole directories can be manually included or excluded by single
  167.       clicking on them in the file requestor.  Double clicking on a
  168.       directory name changes to that directory.  All non-empty directories
  169.       have a much-greater-than sign (») appended to their name denoting that
  170.       they may be entered.
  171.  
  172.    4) Finally, individual files can be selected (unselected) by single
  173.       clicking on them in the file requestor.
  174.  
  175. After choosing the files to be backed up, the user can press the buttons for
  176. each of the floppy drives BackUP will use during the procedure.  It is
  177. recommended that as many drives be used as available.  BackUP automatically
  178. formats disks as it writes and also switches between drives without any user
  179. intervention (continuous write).  This speeds the process up by constantly
  180. writing to one drive while the user is changing the disk in another.
  181.  
  182. Finally, two options may be set in the menu bar:  compression and verify.
  183. BackUP performs on-the-fly compression by reading in small (11K) blocks of
  184. files, compressing them and asynchronously writing them to disk.  The
  185. asynchronous part allows BackUP to read from the hard drive and write to
  186. the floppy drive simultaneously.  Compression can reduce the number of
  187. disks used by a factor of two (I have seen 2MB written to 1 disk).
  188. Compression can, however, slow down the backup since the compression
  189. process takes time and degenerates the backup to a synchronous process
  190. (read, compress, write).
  191.  
  192. The verify option specifies whether a read pass of the tracks written to
  193. the floppy is made after the format/write pass.  The backup process is sped
  194. up considerably with verify off, however, it is not recommended since the
  195. integrity of the data is unknown.
  196.  
  197. All of the options (include/exclude wildcards, compression state, verify
  198. state, backup type and floppy drives used) can be saved as the defaults by
  199. choosing the "Save Configuration" option in the menu.  Upon subsequent boot
  200. ups, BackUP will load the configuration file and automatically set the
  201. previously saved defaults.
  202.  
  203. After all this is completed, the user need only press the "Start Backup"
  204. button and begin swapping disks.  During the backup, a fuel gauge bar fills
  205. representing the completion of the backup.  Also, the current file being
  206. backed-up as well the current disk being written to and the total number of
  207. files and bytes backed-up is constantly updated.  The disks should be
  208. labeled by date and disk number since BackUP will request numbered disks
  209. during the restore procedure.  The user may halt the process at any time by
  210. pressing the "STOP" button.  Note that the process will not actually stop
  211. until the current file is completely written.
  212.  
  213. After the files are copied to floppy, BackUP writes out the directory
  214. structure.  Only the directories that contain backed-up files are written in
  215. order to save space.  This means that, on full backups, empty directories
  216. will not be saved, and, therefore, cannot be restored.
  217.  
  218. ----------------------------------------------------------------------------
  219.  
  220.                                   RESTORE
  221.  
  222. The restore procedure is very similar to the backup procedure with the
  223. exception that the list of files is read from the floppy set instead of the
  224. hard drive.
  225.  
  226. When BackUP boots up, the user need only press the "Start Restore" button
  227. to have BackUP read a partition's directory structure off floppy.  BackUP
  228. will request that the last disk of a backup set be inserted into the first
  229. available drive to start this process.  BackUP may ask that the previous disk
  230. be inserted depending if the directory structure write overlapped multiple
  231. disks.  When finished, the user can select and deselect files just as in the
  232. backup procedure with the exception that the Incremental/Full button is not
  233. available.
  234.  
  235. After choosing which files to restore the user should press the "Start
  236. Restore" button again.  The same window with fuel gauge bar will appear
  237. and BackUP will request particular numbered disks to be inserted in the
  238. available drives.  Files are restored to their previous location with date
  239. stamp, file note and protection bits restored as well.  Directories will be
  240. made if necessary.
  241.  
  242. ----------------------------------------------------------------------------
  243. ***************************** Known Problems *******************************
  244. ----------------------------------------------------------------------------
  245.  
  246. There are two known problems with the program.  The first is that although
  247. a "CANCEL" button is included on a number of popup requestors, it is not
  248. always implemented and therefore pressing it just brings up the same 
  249. requestor.  This is true only for requestors with red text (as opposed to
  250. white) that appear in the middle of screen that usually request that a disk
  251. be placed in a drive.
  252.  
  253. The second problem is with BackUP's handling of bad disks.  BackUP makes
  254. three (3) attempts at writing to a track.  If all three fail, a requestor
  255. will come up asking if you wish to continue or abort.  Aborting will blow
  256. the user out of the program (not graceful).  Continuing will simply skip
  257. that track on proceed to the next one (recommended).  However, if BackUP
  258. encounters a large number of tracks that are bad sequentially, it seems to
  259. get confused an cannot recover them (ouch).  The moral, use known good
  260. disks.
  261.  
  262. These problems are currently being looked into, and, when dealt with, an
  263. update to BackUP will be made.
  264.  
  265. ----------------------------------------------------------------------------
  266. ****************************************************************************
  267. ----------------------------------------------------------------------------
  268.