Club Amiga de Montreal - CAM/CAM_CD_1.iso/files/391.lha/MRBackup_v4.0b/Changes

Text File | 1990-06-03 | 13.5 KB | 288 lines

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<something>:"  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.