Stewart is correct. A file backup set's catalog is stored in the file's
resource fork, which cannot grow past 16 MB in size. This issue is covered
in the 4.3 Read Me and Retrospect Help.
Solving this problem requires *significant* changes to Retrospect's backup
set architecture--it's not a simple matter. We are working to address this
issue with a future release.
In the meantime, the Retrospect Help file suggests the following
o Perform a recycle backup to the file backup set, which
clears the catalog and starts anew. (Backed-up data in
the set is removed.)
o Perform a new media backup to the file backup set, which
creates a new, empty file with an empty catalog. (The
old file is left intact with its backed-up data.)
o Do not try to copy so many files or volumes to the file
backup set. Consider creating separate backup sets for
o Stop using file backup sets and instead use CDs, disks,
or tapes. You may transfer backed-up data in file backup
sets to other kinds of backup sets.
o Leave the catalog compression option on (it is on by
default) to help keep down the size of catalogs.
I hope this helps.
Stewart Macdonald <[EMAIL PROTECTED]> wrote:
> Lawrence E. Bakst ([EMAIL PROTECTED]) recycled some electrons by writing:
>> Can anyone comment if the 16 MB catalog limit is going to fixed soon?
>> Are there any other limits I will run into after this one. Can
>> someone describe why this limit exists? My guess us that there is a
>> 24 bit quantity in a data structure that causes the limit and that
>> the other byte is used for something else. If that is the case, it
>> doesn't sound too hard to fix.
> I believe that the manual says that this is due to the 16MB limit on a
> file's resource fork. The catalogue is stored in the Resource fork, so you
> get the limit. I guess if Dantz changed the location of the catalogue, it'd
> remove the limit.
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]