Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!zardoz.cpd.com!dhw68k!felix!art
From: art@felix.UUCP (Art Dederick)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: Strange zoo problem
Keywords: zoo bug
Message-ID: <159747@felix.UUCP>
Date: 27 Mar 91 21:22:14 GMT
References: <27DAF021.3ABD@ibma0.cs.uiuc.edu> <695@sun4dts.dts.ine.philips.nl>
Reply-To: art@felix.UUCP (Art Dederick)
Organization: FileNet Corp., Costa Mesa, CA 92626
Lines: 23

I believe the problems with zoo being reported are due to memory space
and not to a bug in zoo.  I have created zoo archives in the
multi-megabyte size and have found only when I run out of free memory
do I ever have a problem, usually trying to update one of these
megabyte archives.  When zoo is asked to update an existing archive,
it must read all entry headers and keep them in memory so it knows
which files need to be updated.  Once zoo runs out of memory, updates
no longer work.  I'm sure RD didn't expect people to use this as a
backup tool so didn't take into account that the number of header
entries would ever be a problem.

To get around your problem, pack the archive before each update and/or
delete then pack those entries you will be updating.  Since the source
to zoo is all over the world (check your local archive site) you can
always modify zoo to use a disk file to keep track of the headers.
Expect slower updates since zoo will then have to search the disk file
instead of just searching memory.

RD - you might want to add an option or put huristics into the next
version of zoo to allow this.

D. Art Dederick (714)966-3618 {ccicpg,hplabs,oliveb,spsd,zardoz}!felix!art
FileNet Corp., 3565 Harbor Blvd., Costa Mesa, CA 92626