Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!uwvax!tank!eecae!netnews.upenn.edu!eniac.seas.upenn.edu!jeff
From: jeff@eniac.seas.upenn.edu (Jeffrey M White)
Newsgroups: comp.protocols.appletalk
Subject: Re: CAP/macdumpmgr problem (another problem/question)
Message-ID: <10433@netnews.upenn.edu>
Date: 26 Apr 89 15:42:05 GMT
References: <1457@epistemi.ed.ac.uk>
Sender: news@netnews.upenn.edu
Reply-To: jeff@eniac.seas.upenn.edu.UUCP (Jeffrey M White)
Organization: University of Pennsylvania
Lines: 18


  I just also picked up the code, and I have a problem and a question about it.
First, I tried it on my IIx with an 80 Mbyte hard disk, about 61.5 Mb used and
15.5 M free at the time of the backup (not sure where the remaining space is.
Macdump created a backup file that was over 98 Mbytes.  Since I assume it is
only backing up the actual files (as opposed to trying to do an image backup
of the disk), this amounts to a 3:2 increase in file size (98:61).  Is there
a reason for this?  
  Second, it is possible to select individual files and/or folders to be backed
up?  In real life there are usually only a specific group of files (letters, 
reports, etc.) which need to be backed up.  Even though the next incremental 
should be much smaller, most systems don't have enough free space to handle the
initial full backup (I got lukcy we had an empty partition).  If this could
be done, it would certainly make the program more useful.

						Jeff White
						University of Pennsylvania
						jeff@eniac.seas.upenn.edu