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