Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!rutgers!rochester!pt.cs.cmu.edu!cadre!pitt!cisunx!ejkst From: ejkst@cisunx.UUCP (Eric J. Kennedy) Newsgroups: comp.sys.amiga Subject: Re: Arp bug? Keywords: arp crashes taking vd0: with it, and in spite of Gomf2.2 Message-ID: <10661@cisunx.UUCP> Date: 27 Jun 88 02:39:43 GMT References: <626@osupyr.mast.ohio-state.edu> Reply-To: ejkst@unix.cis.pittsburgh.edu (Eric J. Kennedy) Organization: Univ. of Pittsburgh, Comp & Info Sys Lines: 27 In article <626@osupyr.mast.ohio-state.edu> vkr@osupyr.mast.ohio-state.edu (Vidhyanath K. Rao) writes: >The second guess, and my money is on this: arp routines read in all the >file entries before doing pattern matching rather than match patterns one >by one. I.e. instead of doing: ExNext(); PatternMatch(); if (matched) pass the >name along; UnLock(); loop >they do ExNext(); etc loop, UnLock everything. I can live with the latter if >there is no hidden bug coming alive when the data space is >32K or number of >files >127 etc. I've noticed a similar situation using the ARP copy command, i.e., it copies each file, and then closes each file. I was using copy vol1:file1 vol2:file2 vol3:file3 vol4:file4 ... TO ram:temp where vol{1,2,3,4,...}: are separate floppies. After getting requesters to "please insert volume ???? in any drive" in the order above, I then get a series of requesters in reverse order, after ram:temp is already created and full. Sounds to me like ARP isn't releasing the file locks until it is completely finished, which could definitely create the kinds of problems you're describing. In my case, I wasn't using enough files to create a problem, just enough to create some unwanted disk swaps. -- ------------ Eric Kennedy ejkst@cisunx.UUCP