[Coco] basic09 - append to file

[gene heskett]

On Thursday, January 13, 2011 08:13:16 pm Willard Goosey did opine:

> On Thu, Jan 13, 2011 at 03:41:41AM -0500, gene heskett wrote:
> > I was up and decided to try an older version of bru, 1.2, and its
> > working right now, but I think I see a problem before its done.  Even
> > with sas=ff on the target drive, the FD.SEG's are filling up too
> > fast.
> > {t2|07}/S1:filext
> 
> Has it finished yet?  Did it work?
> 
Yes, finished early this morning and a -t run on it, seems good.  By not 
having all those FD sectors in the backup, just the files, it actually 
shrank a somewhat surprising amount, to just over 88 megabytes.  And used 
only 15 of the possible 48 fd.seg entries.

> >BTW, I consider that rollover at $8000 a bug, but it may be a shrug
> >too.  I may be the only person in history to generate a single 100+
> >megabyte file on a coco.
> 
> Well, from what I understand from 3rd-party docs, classically, OS-9
> likes user programs that are going to use huge files to pre-allocate
> them.  For bru to do that, it would have to know how big  its output
> file was going to be, and how big its backup media is.

True, and that of course it has no knowledge of at any point till it 
finally hits the EOF of the root directory with no children still running.

Pre-allocating this would have also required the allocation request to have 
ben submitted in pieces small enough it would fit in an INT.

That would also overflow the 2 bite assignment given each FD.SEG's 
allocation size.  Aided in the management in this case is the cluster size 
of 16, so an FD.SEG extant of $8000 means each FD.SEG can represent a bit 
over 8 megabytes before it has to allocate another FD.SEG.  So it worked 
out well I believe.

> >Of course probably 75% of it is just
> >because I'm a packrat & really should do some housekeeping.  ;-)
> 
> Packrat away, my friend.  Just think about where we'd be if
> maltedmedia went away like PUCC and chestnut. Or when RTSI crashed and
> they didn't have a backup?

Shudder.  I'd druther not have to face that again.  If worse came to worse, 
I probably have 20% of rtsi 6x09 tree here, and could help restore it.  
Between the bunch of us I think we could do a decent job of restoring the 
6x09 tree at least.  One thing is for sure, I would get rid of some of my 
less than stellar earlier versions of some of my utilities.  One keeps on 
developing useful stuff, bug fixing etc, and there are early versions of 
some of my stuff out there that shouldn't ever see the light of day again 
if lost.

Here, a lot of it is just because I took something apart to see how it 
worked, maybe even made my local copy better, but never had the heart to 
nuke it once I was finished, emphasizing that old saw that says "a program 
is never truly finished until someone shoots the programmer." ;-)

Another saying talks about the trouble with trouble shooting is that 
trouble often shoots back.  Attributed to "Some guy on the internet". ;-)

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Non-Reciprocal Laws of Expectations:
	Negative expectations yield negative results.
	Positive expectations yield negative results.