🚀 go-pugleaf

In article <16819@cs.yale.edu> fischer-michael@CS.YALE.EDU (Michael Fischer) writes:
[Micheal writes about the 40-folder bug]...
>TOS 1.0 and 1.2 used the memory less wisely and had varous bugs in the
>management of the pool that could cause the machine to crash.  In
>particular, it failed to check properly when the pool was exhausted,
>so when too many folders or too many Malloc's used up the pool, weird
>things would start happening.  The so-called "40-folder" limit was
>just an empirical observation that users who had at most 40 folders on
>their disks were unlikely to exhaust memory.  Thus, as long as one had
>at most 40 folders, the problem would not usually be encountered.  By
>increasing the size of the pool, FOLDRXXX allowed more folders to be
>used.

I have just got a Hard Drive after 3 months of waiting for Power
Computing to come up with it (just thought I'd add that dig). Now that I
have all this disk space the 40-folder bug must be more likely.

Can someone explain exactly what causes the memory to be used up. Is it
creating folders/opening folders or both? I have installed foldr100 but
I'd like to have some sort of empirical measure of how long I can muck
around with my drive (setting it up etc.) before I should reboot.

Also, what are the symptoms of the bug? Does the machine crash or would
things like having several copies of the one file (with the same name) in
the same directory be a possible consequence? This happened to me last
night but I wouldn't like to jump to conclusions - I'd been compiling a
C prog which refused to do anything but bomb out, but my ST kept on
going (it didn't lock up) so normally I would have thought that was the
cause. 

While I'm on the subject, what does *one* bomb mean? Neodesk didn't know
and either did any of my books....

>| Michael Fischer                                |
>|    Arpanet:    <fischer-michael@cs.yale.edu>   |