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: Date: Sat, 6 Apr 1991 17:03:51 GMT Lines: 31 In article 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