🚀 go-pugleaf

canada@crash.cts.com (Diane Barlow Close) writes:
>From    : John Sudikatus
>A WARNING TO ALL TOS 1.4 USERS!!!
[message precis: "perhaps the 40-folder bug is back in a new guise"]
>1.0) another bug was introduced. It seems that the directory buffers
>now overlap slightly with the dynamic memory pointer list. This means
>that when you have accessed more than about 35 folders and then try to
>allocate memory, there is a good chance that the program will bomb
>horribly.

This note is not a flame, but a request for information and also a
data point for those debugging:

Bug:  zoo.ttp, arc521.ttp die horribly under suspicious circumstances.

Environment: 1040 expanded to 2.5Mbytes, TOS 1.4 of 6 April 1989 in
	ROMs, Supra adapter & boot software rev 3.41 (? sorry, its @
	home), Quantum Pro80 scsi drive, partition C is 32 Mbytes and
	contains 195 directories and 1700 files (+/- 5%).  Running
	CACHE256.PRG in AUTO\, but not FOLDRnnn.PRG.  Have a blitter.
	Running CONTROL.ACC, no other .ACC's; 200 Kbyte ram drive on
	H: (EDISK.PRG).

Repeat-by: from desktop, run menu File/Info against drive C icon.
	Reports indicates 6.1 Mbytes free on C:; invoke Marc Williams
	Co MSH.PRG (version 3) to obtain shell, run MF.TOS (a utility
	of mine own creation :-) and observe 1.9 Mbytes free RAM.

	Then cd off to a directory 4 levels down
	(c:\arch\utl\src\emacs3v9) and run 'zoo aM emacs.zoo *'.  Zoo
	runs along nicely for about 8 files and then reports 'file
	baz: read error' or 'input error on baz' or something along
	those lines.  Cat'ing the file to stdout shows no problems.
	Rerunning zoo gets the same error at the same place again.
	Running 'arc521 a emacs.arc *' gets a 'write error: no space
	on disk??'  at a different file, which again cat's out in a
	normal fashion, and again the fault is consistent and
	reproducable; there is still 5.5 Mbytes free on the partition
	according to DF.PRG.  This general pattern could be repeated
	in many different directories; the Supra utilities report the
	disk is error free.

Workaround-by: I ended up using gnutar and compress.  No problems
	ever.

Hope someone can make something of this.  My suspicion: gnutar does
lots of I/O but only allocates a little memory.  Compress allocates
one largish (~500k) chunk before it starts doing I/O, but none
thereafter.  Am I correct in guessing that zoo and arc tend to
allocate and release memory in a fairly dynamic fashion while doing
large amounts of I/O concurrently?  According to the posted bug
report, this would tend to excercize the buffer-pool vs. free-list
collision bug... or so I surmise.  Help?

	Ross