jrk@information-systems.east-anglia.ac.uk (Richard Kennaway CMP RA) (11/26/90)
I recently posted a query about why I could often not run a program, due to insufficient memory, even when "About the Finder" appeared to show that the Largest Unused Block was 100 or 200K larger than required. I didn't get a solution to that problem, but now I have what looks like a similar one: In certain circumstances, I can't copy or duplicate any files because "Ran out of Finder memory during copy. Please drag the items in two groups". Even if I'm only copying one item, and that only a few K in size. This is in spite of the fact that "About the Finder" shows plenty of space in the Finder's partition (nearly half free out of a partition size of 300k), and a Largest Unused Block of about 150k. Quitting an application, releasing 400K, lets copying go ahead. There is also free space in the System partition (about 10% out of 1200k). The only other hint I can give is that this sort of thing seems to happen more often if I have printed something since booting. In fact, I suspect that it has never happened before having printed anything. But this may just be coincidence. I haven't been able to reliably reproduce the behaviour. Is it possible that PrintMonitor, or something else, is leaving unrelocatable blocks lying around in what should be free space? Version numbers, as reported by MacEnvy: System 6.0.5, Finder B1-6.1.5, MultiFinder 6.1b9, Mac IIfx. And the first time I tried to open the Control Panel to use MacEnvy, I just got a beep - not enough memory to run DA Handler. -- Richard Kennaway SYS, University of East Anglia, Norwich, U.K. Internet: jrk@sys.uea.ac.uk uucp: ...mcsun!ukc!uea-sys!jrk
francis@daisy.uchicago.edu (Francis Stracke) (11/27/90)
Maybe you've been virized. | Francis Stracke | My opinions are my own. I don't steal them.| | Department of Mathematics |=============================================| | University of Chicago | Until you stalk and overrun, | | francis@zaphod.uchicago.edu | you can't devour anyone. -- Hobbes |
jrk@information-systems.east-anglia.ac.uk (Richard Kennaway CMP RA) (11/28/90)
In reply to my description of strange out-of-memory reports from the Finder, in message <1990Nov27.025958.11357@midway.uchicago.edu>, francis@daisy.uchicago.edu (Francis Stracke) writes: > Maybe you've been virized. That's always possible, but if so, it's a virus that can hide from GateKeeper Aid 1.1, GateKeeper 1.1.1, Disinfectant 2.3, and Virus Detective 4.0.3. Correction to my earlier message: I have now observed the behaviour without having printed anything since booting. All I'd done was run Telnet, Word 4, and mount and dismount an AUFS volume. Then I couldnt open MacDraw II, although there should have been room. I still cant make it happen reproducibly though. -- Richard Kennaway SYS, University of East Anglia, Norwich, U.K. Internet: jrk@sys.uea.ac.uk uucp: ...mcsun!ukc!uea-sys!jrk
alen@crash.cts.com (Alen Shapiro) (11/30/90)
In <12570.9011281439@s4.sys.uea.ac.uk> jrk@information-systems.east-anglia.ac.uk (Richard Kennaway CMP RA) writes: >Correction to my earlier message: I have now observed the behaviour >without having printed anything since booting. All I'd done was run >Telnet, Word 4, and mount and dismount an AUFS volume. Then I couldnt >open MacDraw II, although there should have been room. I still cant >make it happen reproducibly though. I've run across a similar problem - here's an experiment to try... Try the above sequence a) with many volumes mounted and b) with few volumes mounted. If the problem gets worse/better (in that order) try increasing the buffer size allocated to finder using Layout 1.9 (or more recent if one is available). This buffer size is NOT the "File:Get-Info" startup memory allocation but some internal finder allocation that layout can change. I've noticed that this internal space affects file copying, application launching, system reliability.....Apple please take note - it is not nice to have the system crash during a file copy (from finder) just because internal mount buffers are used up!! --alen the Lisa Slayer (trying to turn a SPARC into a flame) alen%shappy.uucp@crash.cts.com (a mac+ uucp host - what a concept!!) alen@crash.cts.com
peter@hari.Viewlogic.COM (Peter Colby) (12/08/90)
In article <5996@crash.cts.com>, alen@crash.cts.com (Alen Shapiro) writes: |> In <12570.9011281439@s4.sys.uea.ac.uk> jrk@information-systems.east-anglia.ac.uk (Richard Kennaway CMP RA) writes: |> |> > [...] |> |> I've run across a similar problem - here's an experiment to try... |> |> Try the above sequence a) with many volumes mounted and b) with |> few volumes mounted. If the problem gets worse/better (in that order) |> try increasing the buffer size allocated to finder using Layout 1.9 |> (or more recent if one is available). This buffer size is NOT the |> "File:Get-Info" startup memory allocation but some internal |> finder allocation that layout can change. |> |> --alen the Lisa Slayer (trying to turn a SPARC into a flame) |> alen%shappy.uucp@crash.cts.com (a mac+ uucp host - what a concept!!) |> alen@crash.cts.com OK, exactly what is the identification of this "internal" finder allocation. I tried both Layout 1.9 and ResEdit 2.0b2 LAYO template and in niether case could I find anything even closely related to some internal allocation or buffer size. Peter C -- (O)(O)(O)(O)(O)(O)(O)(O)(O) (O)(O)(O)(O)(O)(O)(O)(O)(O) (O) !the doctor is out! (O) (0) peter@viewlogic.com (0) (O)(O)(O)(O)(O)(O)(O)(O)(O) (O)(O)(O)(O)(O)(O)(O)(O)(O)