Path: utzoo!attcan!uunet!mcrware!davely
From: davely@mcrware.UUCP (Dave Lyons)
Newsgroups: comp.os.os9
Subject: Re: Err. 217
Message-ID: <1450@mcrware.UUCP>
Date: 8 Jan 90 16:53:46 GMT
References: <1123100003@stasys> <5936@sdcc6.ucsd.edu>
Reply-To: davely@mcrware.UUCP (Dave Lyons)
Distribution: comp
Organization: Microware Systems Corp., Des Moines, Iowa
Lines: 33

In article <5936@sdcc6.ucsd.edu> pa1412@sdcc13.ucsd.edu (pa1412) writes:
|In article <1123100003@stasys> fkk@stasys.UUCP (Frank Kaefer) writes:
|
|+don't get error 217 too often. But I think there should be another
|+solution to the problem (copying the file can only prevent err. 217 for
|+a little while).
|
|Yeah, re-write RBF and make the last segment table entry be a
|pointer to the next segment table block. Then cache all the blocks
|on open. Each open will have more time overhead and the new RBF
|would take more space but with fast processors speedy SCSI and megs
|of ram all problems go away.

[stuff deleted]

|But if the Microware gods are listening, I would like a little
|rethink in this area.
|--
|John Clark

What you suggest is exactly what is done in OS-9000 RBF.  I guess that
being the "gods" we are, we forknew that you would suggest this 8^).
Actually, with so many people complaining about the 217 problem (inc-
luding me) over the years, allowing an unlimited number of segments 
was one of the major design goals for the new RBF along with sector
sizes other than 256 bytes.  See Ric Yeates and James Jones article in
this space for more info on new features in OS-9000.

-- 
           Dave "Not the Apple Guy" Lyons - uunet!mcrware!davely
------------------------------------------------------------------------
 "We can't fight you.  We're totally weak" - Bill S. Preston, Esq.
              My employer laughs at my opinions.