Changes ======= This file lists changes, in reverse chronological order, as they have appeared in official releases of MRBackup. I have attempted to be thorough, but may have missed a few key items. Version 4.0a, May 15 1990 If the WorkBench screen is in interlace mode, MRBackup will open an interlace screen, also. In that case, the Status Display window is positioned below the bottom edge of the MRBackup Parameters window. Version 4.0b, May 1990 If you used any filters, there was a chance that MRBackup would crash after completing a backup. This was due to a bug in the routine which frees memory from the filter lists. ========================= | Version 4.0, May 1990 | ========================= I think you're gonna' like this one! New Screen Layout ----------------- It will be obvious that the screen layout has changed once again. I saw all those nice NeXT-like programs popping up all over and I decided that I liked the 3-D look. You almost get the sense that you could reach up and feel the texture of those raised surfaces, push the buttons on the window, etc. What you see here is my attempt to imitate that. I hope you like it (or at least don't find it disagreeable). The color scheme has changed somewhat to acommodate this new look. I was sorely tempted to go back to an 8-color screen but I fought the urge. The color scheme is as follows: Color 0 - background Color 1 - Text Color 2 - top-left borders Color 3 - bottom-right borders Unfortunately, this means that ALL text on the screen is the same color. I liked the differentiation between "label" text and "contents" text, but it just didn't seem to work with the multi-colored borders and only 4 colors. By the way, picking four compatible colors is even HARDER with this type of presentation. I've picked two different layouts for you to start with. The New Status Display Window ------------------------- I didn't really want to create another window, but it was either that or squish everything in the Main Window down to an unreadable size. Thus, the Status Display window was born. This window reports Backup and Restore progress information as well as certain error or status messages generated while interacting with MRBackup. Hint: if you run in Interlace mode, the Status Display window and the MRBackup Parameters window will peacefully coexist without overlapping one another. In response to the endless cajoling, pleading and downright nagging, I've finally added automated support for multiple floppy drives. This release makes one rather large assumption - that all of your trackdisk-based floppy drives are named "DFX:", where "X" is in the range 0 through 3. If you have more than 4 floppy drives, more power to you, but they won't be recognized by this scheme. If you have floppy drives with a different device prefix (perhaps you've created a New Amazing FileSystem and your floppies mount as "DX0, DX1, etc."?), MRBackup will thumb his nose at them. I had to start somewhere, and the "four drives or less and device name = DF:" assumption would seem to address the greatest common denominator of Amiga users. I'm all ears if you have different requirements, however. Just tell me what you need. Here's how multi-floppy support works: On the main window, note that there are four floppy drive icons (gadgets). The icons for drives you don't have are disabled (ghosted), while those that are available are enabled. IMPORTANT! If you select one or more of the floppy drive icons, the "Backup Path" gadget is ignored. Each selected floppy drive icon will display a checkmark and its "shutter" will have "opened". When you start a backup or restore, MRBackup will first check the selected drives to see if any disks are present. If so, you will be required to remove them. This is for safety. You will then be requested to insert floppy disks into each selected drive. You can tell MRBackup "NO" at this point or you can tell him "YES" (meaning the request was satisfied). In fact, you can LIE to MRBackup by not loading some or all disks but responding with "YES". This would be appropriate at the end of a restore sequence when you have fewer disks remaining than the number of drives selected. If MRBackup discovers an empty drive, he'll place a specific request to have it loaded, just as in previous versions. Once the disk units are filled, MRBackup will happily munch away on them in ascending unit order until the highest numbered selected unit has been filled (backup) or emptied (restore). This will allow you to make less frequent trips "back to the barn" to feed your floppy drives. Thanks for pushing me, everyone! I really like this new feature. I had a lot of inertia when it came to implementing it, however. I think I was looking for a solution which was too "open-ended". Once I decided to take this approach, it all fell into place very quickly. !!! New Filter Files !!! ------------------------ In previous versions, MRBackup had an "exclude filter" (default name = MRBackup.xcld) which would allow you to prevent certain files from being backed up. We now have a totally new, much more orthogonal approach. The exclude filter file is gone and, in its place, we have the (sound of trumpets) "Backup Filter". Yeah! In the backup filter file, you can both specify files you wish to exclude and files you wish to include. This brings a tremendous new range of file selection power to your fingertips! (I know - I'm starting to sound like the Salad Master guy on T.V. :-) The backup filter file essentially has two modes, :INCLUDE: and :EXCLUDE:, which you can toggle back and forth by the presence of the magic words :INCLUDE: and :EXCLUDE:. The initial state is :EXCLUDE:. Since you already know all about the :EXCLUDE: mode, I'm just going to talk about the :INCLUDE: mode. If any include patterns appear in the backup filter file, the relative portion of the Home Path specification is ignored (i.e. only the device name portion is used). Note that the include patterns must define FILE names, NOT DIRECTORY names (as opposed to exclude patterns which can specify either). If you want to include everything in a particular directory, follow the directory name with a slash and either "#?" or "*" (omit quotes). For instance, to include all files in directory "Documents/Unix" you would include the pattern "Documents/Unix/*" or "Documents/Unix/#?". Suppose you wish to backup EVERY directory on your system which contains documentation and you have consistently named them such that the first three letters are always "doc". In addition, you want to omit any file containing the pattern "ReadMe". I don't know why you'd want to do it - maybe you're just wierd. The following patterns would do what you want: :INCLUDE: ; Include all files in all directories whose names start with "Doc". (Doc/#?|#?/Doc#?/#?) :EXCLUDE: ; Exclude all files whose names have "README" embedded within them. #?README#? ; The backup filter works IN CONJUNCTION with your other backup parameters. The order of testing is as follows: 1. Is file modification date greater than or equal to test date? 2. If "Test Archive Bits" is on, is this file's archive bit CLEAR? 3. Is file not excluded by an :EXCLUDE: specification? 4. If :INCLUDE: specifications exist, does file name match an include list entry? If the file passes all tests, it is selected for backup. Decompression Filter -------------------- In prior versions, you had a compression filter which would let you prevent certain files from being compressed during a backup. This was primarily to head off the "file expanded while being compressed" syndrome, typical with most archive files (ARC, ZOO, etc.) and certain graphics image files. Now you have a decompression filter, as well! The default decompression filter filename is "S:MRBackup.dflt", but you can override that and your choice can be saved in your MRBackup preferences file (MRBackup.init). During a restore, the decompression filename pattern list will be consulted. Any filename matching a pattern in this list will not be decompressed. This can be quite useful if you maintain directories of files which are normally compressed (my online documents are stored this way). IMPORTANT: MRBackup only recognizes filenames ending in ".Z" as potential compressed files. If your pattern specifications name specific files, you MUST include the ".Z". For example: ; The ".Z" is not required here, since we are being non-specific. Documents/#? ; The ".Z" is required here, because we are being very specific. MyArchives/Misc/MyVeryBigFile.Z ; Compression ----------- Limited testing reveals about a 25% boost in performance during compression. I'd be interested in hearing what your impressions are. Also, there are two new built-in compression filters: "#?.LZH" and "#?.ZIP". Since these are very prevalent, I decided they should be part of the standard set. Buffer Size Gadget ------------------ This was primarily added for those of you who have gobs of RAM and are looking for ways to use it. The Buffer Size gadget allows you to specify the amount of memory to use per file for buffering. The value is specified in K (multiples of 1024 bytes) and must be at least 2 (2048 bytes) and no greater than the largest Available chunk of memory. A better upper limit would more likely be something like 128K. Increasing the size of the buffer used will decrease the number of explicit writes to the disk unit, enhancing performance. Utilities --------- If you inadvertently place trailing blanks in the File Spec gadget, they will be truncated. (Thanks, Tom Zartler) Previous releases required the use of the shift key to select multiple files. This is no longer the case. Each click on a filename will toggle between selected and not selected. Bug Fixes --------- In version 3.4f, files named ".info" (the files that track icon positions) within a given folder) would confuse MRBackup in his attempts to associate files having a ".info" suffix with a parent file. This has been rectified in version 4.0. In some cases, an output error could be missed if it occurred at the very end of writing a backup file. This has been corrected. Empty directory hierarchies are now preserved and directory comments are also preserved. =========================================================================== Versions 3.4e and 3.4f, April 1990 I've been chasing a mysterious "Out of memory!" condition (A2000, 1MB CHIP RAM) since V3.4c. I finally found the culprit. One of my ancient library routines was making an explicit request for fast memory. I thought I had "re-educated" all of my support stuff but this one apparently slipped through the cracks. Fat Agnus exposed the problem. New machines have 1MB chip memory and no fast memory. Thus, explicit requests for fast memory (which are just plain dumb!) will fail on these machines. I apologize. I discovered another problem with file decompression when using Restore. There was an erroneous test on the "Compression" setting which should have been testing the "Decompression" setting. Thus, if you had "Compression" set to None it would disable decompression - ugh! More work has been done on the compression/decompression buffer management. Prior to this release, the compression/decompression buffer was being allocated/deallocated on a file-by-file basis (this was actually new in 3.4c). This proved to be somewhat "dangerous" due to the large size of the contiguous memory block required. Subsequent smaller memory allocations would cause fragmentation and a larger buffer, if required, could not be allocated. Now MRBackup defers allocation of the buffer until it is required, as before. However, once obtained, it is not released until the backup/restore/utilities operation is done. Running my MemEater program and limiting memory to 1MB CHIP, I was able to do a backup with 16-bit compression and there still was approx. 200K system memory available. At the time, DMouse, dcron, PopUpMenu and a few other background processes were running. I guess you can ignore my previous cautions regarding maximum compression/decompression bit settings. If you're wondering why all this pain has gone into memory management ("Why not just GRAB what you need?"), my goal is to use a minimum of resources and remain multitasking friendly. I had previously released a version of MRBackup which would detach from the current CLI. Unfortunately, I later discovered that each invocation of MRBackup would "lose" 560 bytes of system memory. The problem is somehow related to the fact that MRBackup has overlays. The non-overlaid version (MRBackup.no) doesn't manifest this problem so I've allowed it to keep the detach feature. I'll try to get an answer from the Manx folks as to where the blame lies (their startup code or AmigaDOS process management?). You'll notice that the main window has been tweaked again. There are no functional changes. I just moved a few gadgets and designed some new pushbutton images for the on/off switches. If anyone has some nice 3D button IFF brushes they'd like to send me (anything!), I'd like to use them to jazz up the next major version.