Newsgroups: comp.sys.amiga.programmer
Path: utzoo!utgpu!watserv1!sunee!avadekar
From: avadekar@sunee.waterloo.edu (Ashok Vadekar)
Subject: Re: zoo? why does it grind the disk?
Message-ID: <1991Apr6.170351.13111@sunee.waterloo.edu>
Keywords: zoo
Organization: University of Waterloo
References: <robtu.670882506@mexia>
Date: Sat, 6 Apr 1991 17:03:51 GMT
Lines: 31

In article <robtu.670882506@mexia> robtu@itx.isc.com (Rob Tulloh) writes:
>
>I have noticed that using zoo with files on the command line causes
>it to grind the disk drive several minutes before it really gets down
>to adding files. However, if I pipe the files to zoo, it adds them
>right away. What gives?
>
...
>
>I don't know why zoo would need to thrash the disk to add files.
>Can anyone offer an explanation?
>
>Rob Tulloh
>--
>INTERACTIVE Systems Corp.         Tel: (512) 343 0376 Ext. 116
>9442 Capital of Texas Hwy. North  Fax: (512) 343 0376 Ext. 161 (not a typo!)
>Arboretum Plaza One, Suite 700    Net: robertt@isc.com (polled daily)
>Austin, Texas 78759               GEnie: R.TULLOH (polled monthly)

The code (which is originally UNIX based) does some truely horrendous
things.  Zoo has to position itself in the zoo file to skip past each
existing entry.  Since a compressed file has a header that states the 
size, zoo performs a fseek() to position itself at the start of the next
record (compressed file).  Unfortunately, all fseek() calls are made
with respect to the start of the file (instead of relative to the current
file postion).  This means going back to the start of the file and scanning
forward again, past the point you were already at, and on to the start of
the next header.

Ashok Vadekar

