Path: utzoo!utgpu!bnr-vpa!bnr-fos!bnr-public!schow
From: schow@bnr-public.uucp (Stanley Chow)
Newsgroups: comp.sys.amiga
Subject: Re: Zoo Bug....
Summary: Would buffers help?
Message-ID: <452@bnr-fos.UUCP>
Date: 30 Apr 89 17:13:16 GMT
References: <1215@jato.Jpl.Nasa.Gov>
Sender: news@bnr-fos.UUCP
Reply-To: schow@bnr-public.UUCP (Stanley Chow)
Organization: Bell-Northern Research, Ottawa, Canada
Lines: 31

In article <1215@jato.Jpl.Nasa.Gov> randy@jato.UUCP (Randy Hammock) writes:
>>>I'm running Zoo V2.00 and although i can't believe it,
>>>Zoo has been running for 20 minutes, and STILL hasn't even
>>>gotten around to starting COMPRESSING....
>>>zoo is running in a directory with approximately 60 files in it
>>>of varying lengths and sizes...
>
>>This is a known zoo 2.0 (and earier versions) problem. It does wildcarding
>>in a .. very slow .. way...
>
>If you find that slow, you should try: zoo v <filename>  on a directory
>that has a fair number of files.  I thought zoo had gone berserk and was
>trying to destroy my hard disk.  Once I realized what was going on, I either
>grin and bear the time or let zoo work on files out of ram.


Hmm, I have been using zoo 2.00 for a while and have never noticed any
problem along this line. In fact, I just tried:
		zoo a ram:ttt *
		zoo a ram:ttt f*k*   
in my utilities directory with about 60 files. [Btw, f*k* is for FlamKey, 
not anything nasty.] Zoo starts doing things within a few seconds.

I do have a lot of buffers, may be that makes a difference?


Stanley Chow	..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public
		Bitnet: schow@BNR.CA.BITNET

Disclaimer:  I am not a biologist, so don't believe me when I start
	     talking about zoo's.