AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (12/15/88)
>Date: Tue, 29 Nov 88 17:05:08 GMT >From: Doug Mcintyre > <cwjcc!hal!nic.MR.NET!shamash!com50!bungia!orbit!pnet51!dougm > @TUT.CIS.OHIO-STAT> >Subject: Gs Ram card >[...] There is one Caveat though, the Finder (latest version) has a >bug in copying files to the Ram disk (this is probably where your >errors come from) and that the finder will not be able to copy it. As far as I know, _all_ versions of the Finder behave this way. >I figure the finder just takes the memory and overwrites the memory >that the ram disk is going to be using. Not exactly--the Finder does ask for the memory through the memory manager just like it should. But if you're copying a lot of stuff at once, the Finder can ask for almost _all_ the available memory. If it does that, fills it full of files, and then tries to write all the stuff out to /RAM5, there will be a problem if you have a variable-sized /RAM5 (min < max). If /RAM5 needs to grow by allocating more memory from the memory manager, the needed memory may not be available. If that happens, a write-block request to /RAM5 reports an I/O error back to the OS, the OS reports the I/O error back to the Finder, and the Finder reports the error to you. It would be nice if the Finder would recognize the situation where it is copying data to a variable-sized /RAM5 and use only HALF of the available memory for buffer space. >But if you use standard Prodos/gsos calls (such as from a shell like >APW or ECP) the ram disk operation is just fine, I compile to the ram >disk all the time, and operate on files on the ram disk all the time >in APW or ECP.. The Finder _does_ use exactly the same standard ProDOS|GS/OS calls that APW and ECP use; only the interface is different. (Don't confuse a typed command with an operating system call!) The only reason you don't have a similar problem with APW and ECP is that they copy just one file at a time (you'd have to copy one _very large_ file to get the same problem); the Finder reads as many files as possible into the available memory, which is usually a Good Thing--it can do the copy faster. >UUCP: {rosevax,crash}!orbit!pnet51!dougm Compuserve: 70611,2215 >ARPA:crash!orbit!pnet51!dougm@nosc.mil ALPE: DougMac >INET: dougm@pnet51.cts.com --David A. Lyons bitnet: awcttypa@uiamvs DAL Systems CompuServe: 72177,3233 P.O. Box 287 GEnie mail: D.LYONS2 North Liberty, IA 52317 AppleLinkPE: Dave Lyons