vkr@osupyr.mast.ohio-state.edu (Vidhyanath K. Rao) (06/24/88)
Let me first tell exactly what happened and give two conjectures: I got Maple and was playing on a friend's machine. I decided to copy files onto floppies to see if one can run a crippled Maple with floppies. [I don't have a hard drive yet. my friend's 2000 does]. I did a 'dir >prt: maple: all' and got the list an hour later (!) This was without arp. After I got to my machine, I plooped the floppy with about 135 files with .m extension and a few directories. With arp (all my boot disks except the original distribution workbench have arp on them), I did 'dir df1: #[^.]' I got a list that was strange: not sorted, included the .m files etc. and then GURU. (No task held requester). I installed GOMF2.2}i and tried again. No good. I switched to an 1000. Still that GURU. What is going on? I trust arp pattern matching becuase it works with reasonable sized directories. But still ... 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. A related question: Do FindFirst and FindNext traverse the files in the disk save order or in alphabetical order? If the second, how do you compute the amount of data space to be assigned? (Because, then the whole directory must be read in before doing pattermatch). -Nath vkr@osupyr.mast.ohio-state.edu
vkr@osupyr.mast.ohio-state.edu (Vidhyanath K. Rao) (06/24/88)
I have discovered a serious bug in pattern matching that, to me st least,
raises the specter of people blaming application programs for arp's
faults: I was moving programs around between two disks: One contains
programs seldom used and the other programs I need most of the time.
I did: copy et
delete df1:system/(REXX#?|#?RamDisk)
There are two programs that end in ramdisk: cleanramdisk and deleteramdisk.
Note that they come before rexx#? in alphabetical sort. Rexx#? got deleted
but not #?ramdisk (?!). If the bug is in arp.library, then I hope that
a corrected version gets out soon. Or I can't trust FindFirst(), FindNext()
or even PatternMatch().
BTW, why is no flag listed in arpbase.h for '#'. There is one for '#?'
but it is not the same. (I haven't seen the correct arpbase.h that I got
recently by EMail).ejkst@cisunx.UUCP (Eric J. Kennedy) (06/27/88)
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