Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!rpi!crdgw1!ge-dab!ge-rtp!edison!toylnd!dca From: dca@toylnd.UUCP (David C. Albrecht) Newsgroups: comp.sys.amiga Subject: Re: Zoo Bug.... Message-ID: <267@toylnd.UUCP> Date: 9 May 89 22:41:26 GMT References: <8904290204.AA00910@jade.berkeley.edu> <25674@watmath.waterloo.edu> Organization: Dave & Anne, Charlottesville VA. Lines: 37 In article <25674@watmath.waterloo.edu>, grwalter@watmath.waterloo.edu (Fred Walter) writes: > In article <8904290204.AA00910@jade.berkeley.edu> CRONEJP@UREGINA1.BITNET (Jonathan Crone) 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... > > > >zoo -move cc cc.c config.h dstr.? list.? err.c op.? options.? > > > >all in all, about 12 files.. > > This is a known zoo 2.0 (and earier versions) problem. It does wildcarding > in a .. very slow .. way, and thus if you have lots'a files (60 counts as > lots) it takes a while. Multiply the time it takes to handle one filename > by 12, and I can believe it'd take > 20 minutes. Solutions : be very > patient; execute zoo from a directory where there aren't many files; OR > wait until the version of zoo with this fixed turns up :-) > Really? It wasn't until I installed FFS on my hard drive that I noticed this infinite loop simulation behavior It seems awfully coincidental that it only began happening after the switch. Yes it is a large directory, but it was large before the conversion also. I have taken to doing a 'list >pipe:files (wildcards) quick' in one cli window and a 'zoo