Frozen Fish 1: Amiga

home *** CD-ROM | disk | FTP | other *** search

/ Frozen Fish 1: Amiga / FrozenFish-Apr94.iso / bbs / alib / d7xx / d767 / backup.lha / BackUP / BackUP.doc < prev next >

Wrap

Text File | 1992-11-21 | 22KB | 431 lines

---------------------------------------------------------------------------- ******************************* Legal Stuff ************* November 8, 1992 * ---------------------------------------------------------------------------- BackUP V3.77 © Felix R. Jeske BackUP is a shareware, freely distributable hard drive backup program for the Amiga under Workbench 2.0. If you like BackUP and regularly use it, I would appreciate being sent a $15 contribution to the following address: Felix R. Jeske 3746 North Oleander Avenue Chicago, IL 60634-3210 USA Usenet: fjeske@amiganet.chi.il.us Contributors will receive the latest version of BackUP (I am already adding a few other goodies) plus a few other programs I've written but not published. Contributors of $25 or more will receive the complete copyrighted source in C. Suggestions, comments and criticisms (ouch) are also welcome at the above address or on Usenet. I am quite proud of BackUP and gladly support it. If any problems are encountered, PLEASE report them! The fastest way to get a problem report to me is by leaving e-mail at the above Usenet address. I have sent out disks at my own expense to users who report problems to correct them. DISCLAIMER FELIX R. JESKE MAKES NO WARRANTIES EITHER EXPRESSED OR IMPLIED, WITH RESPECT TO THIS SOFTWARE, ITS QUALITY, PERFORMANCE OR FITNESS FOR ANY PARTICULAR PURPOSE. THIS SOFTWARE IS PROVIDED "AS IS." THE ENTIRE RISK AS TO QUALITY AND PERFORMANCE OF THE SOFTWARE IS WITH THE USER. IN NO EVENT WILL FELIX R. JESKE BE LIABLE FOR DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES RESULTING FROM ANY DEFECT IN THE SOFTWARE. ---------------------------------------------------------------------------- ********************************* Credits ********************************** ---------------------------------------------------------------------------- Many thanks go to the developers of ARP who have created an extremely useful collection of routines in one library and have made it easy to program as well. Also, thanks go to Holger P. Krekel and Olaf Barthel for use of their lh.library. This is an excellent version of the LZH compression algorithm that, again, is very easy to program. ---------------------------------------------------------------------------- *************************** System Requirements **************************** ---------------------------------------------------------------------------- BackUP requires Workbench 2.0, 1MB of RAM, a hard drive (obviously) and as many floppy drives as you can afford. BackUP also requires arp.library V39 (available on FF123, not distributed with BackUP) and lh.library V1 (available on FF436, distributed with BackUP) ---------------------------------------------------------------------------- ***************************** Historical Info ****************************** ---------------------------------------------------------------------------- BackUP was initially developed on a A500 under Aztec C 3.6a. Workbench 2.0 additions were made on a A3000 under Aztec C 5.2a. V3.77 - Converted array indexing to pointers to save code V3.76 - Fixed maximum number of files (2000) on restore problem V3.75 - Fixed internal tracking of bad tracks V3.74 - Added support for hard file links V3.73 - Added optional bell on message and disk change requestors V3.72 - Fixed disk labeling bug V3.71 - Fixed directory selection bug and improved selection overall V3.70 - Improved input-blocking code for multiple requests V3.69 - Added status (Reading..., Writing..., etc.) display V3.68 - Rearranged menu system V3.67 - Added two different types of backup logs V3.64 - Squashed file protection bug V3.63 - Squashed empty file bug V3.62 - Squashed CrossDOS incompatibility V3.61 - Squashed drive motor bug V3.6 - Added color requestor and support for high density drives V3.5 - First public release V3.4 - Added compression using lh.library V3.0 - Discontinued use of req.library and added custom gadgetry V2.0 - Added gadgets using req.library V1.0 - Added primitive interface using autorequestors and the console V0.9 - Initial development of the backup and restore engines I started developing BackUP after my purchase of a $700 (groan) 30MB Supra hard drive. Not wanting to spend any more money than I had to, I started on BackUP after reading about programming the trackdisk.device in an issue of Transactor for the Amiga by Bob Rakosky (August '89: Vol. 2, Issue 5). After figuring out how to do raw reads and writes to the floppy drive, I learned about parsing a partitions directory structure. I heard about ARP in another issue of Transactor and finally got my hands on it. I incorporated req.library after buying CygnusEd which uses it quite heavily. The current version of the code is almost identical to that under req.library except for cosmetics. I borrowed the current gadgetry style from AVS (Application Visualization System), a scientific visualization package I program and use at work on UNIX workstations. Finally, I found lh.library on Fred Fish Disk #436 and included compression as an option. ---------------------------------------------------------------------------- ******************************** Benchmarks ******************************** ---------------------------------------------------------------------------- The target machine for BackUP is any Amiga with at least two (2) floppy drives. Being restricted to one floppy drive eliminates the continuous write feature. BackUP does not support tape drives since I don't have one. Compression is only recommended for fast machines or if you really want to save disks (55% compression is typical) as the on-the-fly compression does slow down the backup. Compression actually speeds up the restore since the speed bottleneck is the floppy read/write time. The decompression process is so fast that reading in less data, decompressing it in memory and writing it out to the hard drive is faster than reading and writing out the original uncompressed data which took longer to load from the floppy. My only real comparison of the capabilities of BackUP to other hard drive backup programs is my experience with HDBackup (shipped with my A3000) and other PD backup programs I've uploaded. Since most of the PD backup programs I've obtained are CLI based, I only compare BackUP and HDBackup since the CLI is not well suited to perform such an operation. Therefore, the following is a comparison of BackUP and HDBackup working on 294 files comprising about 1.1MB of data with compression and verify on. It shows the following: BackUP HDBackup ------ -------- Executable Size 36K 81K Memory Usage 430K 475K While Backing Time to Backup 2:56 4:03 Number of Disks 1 3 I could not figure out why HDBackup needed three (3) disks to backup 1.1MB of data, especially when full compression was enabled. In uncompressed form, it should have only occupied two disks. ---------------------------------------------------------------------------- ******************************* User Docs ********************************** ---------------------------------------------------------------------------- BACKUP The backup procedure consists of selecting the partition to backup, the specific directories and files to backup within the partition, selecting which floppy drives to use during the backup and finally the swapping of disks in and out of the floppy drives. When BackUP boots up, it polls the machine for all hard drive partitions and all floppy drives. A gadget for each is created on the main screen. The user need only press on one of the labeled partition buttons to start reading the complete directory contents into memory. When done, a standard file requestor displays the entire directory structure. A few methods are available to the user as to how files are selected to be included in the backup. The order of the methods chosen is important. For example, selecting a particular file in a directory and then deselecting the entire directory will deselect that file. The following lists the order in which the selection process should proceed. 1) The Incremental/Full button changes whether files with their archived bits set are included in the selected file list. 2) The Include and Exclude wildcard patterns are convenient ways to include/exclude large groups of files. A file is selected for backup if it matches the Include pattern and does NOT match the Exclude pattern. The ARP pattern matching system is used and therefore asterisks (*) can be used in place of Commodore's global wildcard (#?). Also patterns can be ORed together via the pipe (|) operator to form more complex pattern such as: *.(c|h)|*.doc which would match all files ending with either a .c, .h or .doc extension. 3) Whole directories can be manually included or excluded by single clicking on them in the file requestor. Directory names with a highlighted background indicate that all the files in that directory are selected. Double clicking on a directory name changes to that directory. All non-empty directories have a much-greater-than sign (») appended to their name denoting that they may be entered. 4) Finally, individual files can be selected (unselected) by single clicking on them in the file requestor. After choosing the files to be backed up, the user can press the buttons for each of the floppy drives BackUP will use during the procedure. It is recommended that as many drives be used as available. BackUP automatically formats disks as it writes and also switches between drives without any user intervention (continuous write). This speeds the process up by constantly writing to one drive while the user is changing the disk in another. Finally, a number options may be set in the menu bar: compression, verify, logs, beeping and the palette. BackUP performs on-the-fly compression by reading in small (11K) blocks of files, compressing them and asynchronously writing them to disk. The asynchronous part allows BackUP to read from the hard drive and write to the floppy drive simultaneously. Compression can reduce the number of disks used by a factor of two (I have seen 2MB written to 1 disk). Compression can, however, slow down the backup since the compression process takes time and degenerates the backup to a synchronous process (read, compress, write). The verify option specifies whether a read pass of the tracks written to the floppy is made after the format/write pass. The backup process is sped up considerably with verify off, however, it is not recommended since the integrity of the data is unknown. Two types of backup logs are available: sortable and printable. The sortable type simply lists the file, its path, creation date, size and backup status in tab separated columns that can be passed onto other codes to be sorted at will. The second backup log type lists by directory the same information. As the name suggests, it is more appropriate to be printed for future reference. The name of the backup log file can be chosen when either type log file is selected. The current date may be automatically put into the name (in DD-MM-YY format) by placing a %s somewhere in the name. Note also that this name is only a root name and that either .inc or .ful is appended to the log name depending on the backup type. The beep option allows the user to choose whether or not an audible beep is made when a pop up message and/or a disk request is made. This is useful if the user walks away from the machine during the backup or restore process. Finally, the color palette may be changed to suit the user's preferences. As mentioned above, the gadgetry style was modeled off of AVS. The default color map was chosen to enhance the 3D feel of the interface. Please note that users should at least make colors 1 and 8 the same. Complement mode highlighting is used and if these colors are not the same the background color of the buttons pressed in will change. But then again, you may want this. All of the options (include/exclude wildcards, compression state, verify state, backup type, etc.) can be saved as the defaults by choosing the "Save Configuration" option in the Options menu. Upon subsequent boot ups, BackUP will load the configuration file and automatically set the previously saved defaults. After all this is completed, the user need only press the "Start Backup" button and begin swapping disks. During the backup, a fuel gauge bar fills representing the completion of the backup. Also, the current file being backed-up as well the current disk being written to and the total number of files and bytes backed-up are constantly updated. The disks should be labeled by date and disk number since BackUP will request numbered disks during the restore procedure. The user may halt the process at any time by pressing the "STOP" button. Note that the process will not actually stop until the current file is completely written. After the files are copied to floppy, BackUP writes out the directory structure. Only the directories that contain backed-up files are written in order to save space. This means that, on full backups, empty directories will not be saved, and, therefore, cannot be restored. ---------------------------------------------------------------------------- RESTORE The restore procedure is very similar to the backup procedure with the exception that the list of files is read from the floppy set instead of the hard drive. When BackUP boots up, the user need only press the "Start Restore" button to have BackUP read a partition's directory structure off floppy. BackUP will request that the last disk of a backup set be inserted into the first available drive to start this process. BackUP may ask that the previous disk be inserted depending if the directory structure write overlapped multiple disks. When finished, the user can select and deselect files just as in the backup procedure with the exception that the Incremental/Full button is not available. After choosing which files to restore the user should press the "Start Restore" button again. The same window with fuel gauge bar will appear and BackUP will request particular numbered disks to be inserted in the available drives. Files are restored to their previous location with date stamp, file note and protection bits restored as well. Directories will be made if necessary. ---------------------------------------------------------------------------- ***************************** Known Problems ******************************* ---------------------------------------------------------------------------- There are two known problems with the program. The first is that although a "CANCEL" button is included on a number of popup requestors, it is not always implemented and therefore pressing it just brings up the same requestor. This is true only for requestors with red text (as opposed to white) that appear in the middle of screen that usually request that a disk be (re)placed in a drive (usually, truly canceling the request will destroy the backup or restore process). This is not really a problem but a known bad interaction. If BackUP is run with blitzdisk (V2.00 © 1989 Microsmiths), the read partition process is slowed down substantially (the other portions of the code don't seem to be affected). I can only figure that both processes are contending with the CPU and therefore BackUP visibly slows down. If anyone has any ideas as to a fix for this, I'd be happy to hear it. ---------------------------------------------------------------------------- ***************************** Release Notes ******************************** ---------------------------------------------------------------------------- Release Comments V3.77 This version includes some optimizations of array addressing that were converted to pointers. For example, tracks[numtracks++] was converted to *tracks++. This and other small tweeks led to 1100 bytes of code being saved. V3.76 This version fixes a bug concerning the maximum number of files that can be restored. In order to save memory, BackUP dynamically allocates buffers to some initial size, then, whenever they are about to be exceeded, they are resized. BackUP forgot to resize the file buffer (currently set to 1000 files). It is resized correctly during the backup procedure so an unlimited number of files can be backed up (but not then restored). V3.75 This version fixes a long-standing bug that screwed up internal tracking of bad tracks on backup floppies. If a track refuses to verify, internal updates are necessary to reflect the new track numbers at which file data has been moved to. Due to the asynchronous operation, this becomes complicated since data is buffered and verification of data lags behind writing of data. Put simply, BackUP would determine track n-1 is bad when it is ready to write out track n so it would have to move track n-1 data to wherever and track n data to wherever+1. V3.74 This version adds support for hard file links. The link is examined to determine where it is pointing to and this information is save. On restore, the link is restored via MakeLink(). This, however, requires that the destination file be present to be successful. BackUP, therefore, restores all real files first and then restores file links. If the user did not restore the destination file or else intentionally deleted it, the MakeLink() will fail and the user will be informed. Soft link are not yet supported. Directory links are ignored. V3.73 This versions adds an optional audible bell cue when either messages pop up or a disk change is requested. V3.72 This version fixed a bug in the labeling of disks. Proper error checking was not performed to ensure that the disk label was actually written. If a user popped out a disk during the labeling process, the label was not written possibly corrupting the backup set. V3.71 This version fixed the directory selection bug in which BackUP lagged in noting when a directory was selected (i.e., all the files in the directory were selected). In addition, the background color of a selected directory is changed to note its state. V3.70 This version improves the manner in which input is blocked to windows when they are superseded by another request. Earlier versions used a cumbersome system that failed to work on multiple, overlapping user requests. V3.69 This version adds a flashing status display informing the user of the exact operation being currently performed (Reading..., Writing..., Compressing..., Decompressing... and Verifying...). Note that Writing... and especially Verifying... flicker so fast that they sometimes cannot even be seen. V3.68 This version reorganizes the menu system by adding a second menu that is just for the growing list of backup options. The first menu is a standard Project menu. V3.67 This version adds two types of backup log files: sortable and printable. V3.64 This version removes a bug with read protection on a file. A proper check was not made that an error did not occur during the read of a file (as opposed to opening it which was checked). This failure to check the read status also caused a problem if a file was removed during the backup procedure. V3.63 This version removes a serious bug with empty files. Backups made prior to this release cannot restore empty files as they crash the machine (oops!). As a work around, users should remove empty files from the restore list prior to restoring. I found this one restoring my 50MB Quantum onto my new 236MB ST3283N. I also removed a few potential divide-by-zeros if the user backs up zero bytes of files. V3.62 This version removes an incompatibility with CrossDOS. The DIx: and PCx: devices where found by BackUP which called up a system requestor. V3.61 This version actually squashes two bugs 1) the drive motor was left running when the user was informed that the current disk was write protected and 2) a tab creeped into one of the messages which printed as a square block in backup.font. V3.6 This version contains two additional features as per Olaf Barthels request: a color requestor and support for high- density drives. I am uncertain of the latter since I do not own such a drive and cannot, therefore, verify my implementation. I would appreciate user feedback on this. Questions I have concern what happens when a user puts a low-density disk into a high density drive? I am not certain I handle this case correctly since the code I inserted queries drive geometry not disk geometry and I don't think a DD disk can be formatted as HD. V3.5 Original public release.