[Coco] Question for those familiar with rbf.mn

[Gene Heskett]

On Sunday 01 February 2015 08:53:23 Allen Huffman did opine
And Gene did reply:
> > On Feb 1, 2015, at 7:32 AM, Gene Heskett <gheskett at wdtv.com> wrote:
> > 
> > I have not however, looked at the login command to see how it assigns
> > the user number, which of course then becomes the owner. Presumably
> > that is locked to the user name thru password?
> 
> Correct — it’s an entry in the password file. I got used to using
> login/password at Microware, and see I had my MM/1 set up similarly
> and even find traces of that on my CoCo too where I created entries.
> These days, I can’t imagine having my computer not protected by a
> password (even if it’s stored in plaintext on the hard drive ;) so
> I’ll probably have my CoCo doing that again when it’s set up.
> 
> As to user numbers … I might make my BBS ID 1000, and something else
> 2000. Maybe I just like nice round numbers with zeros after it.
> 
> How hard would it be to hack RBF to not use that last FD.SEG entry?
> That wouldn’t break compatibility with any software from anyone
> else. It would only be on your system (protecting what that backup
> program you mention did).
> 
> And what of FD.SIZ? Yes, even OS-9/6809 could support a file up to
> $FFFFFFFF bytes long (4GB - 4294967295). This was the same with OSK
> too, and was an issue with the early Digital TV stuff since video
> files COULD be longer than that - who woulda thunk it in 1980!
> 
> Perhaps there is your byte. FD.SIZ reduced to 3 bytes, with one more
> available, assuming you never have a single file larger than $FFFFFF
> (16MB, 16777215). Or use a bit of that, limiting it to 2GB max file
> size :)  But, that sounds like more work to implement — any utility
> that gets the size from the File ID sector would have problems.
> 
> I think the FD.SEG makes the most sense. Limit RBF to 47 segments
> instead of 48. Though that would break repack tools that look at the
> segment list…
> 
> Nevermind. I don’t like the idea any more :)

More work, but if I just steal the high nibble, that still leaves 4096 
possible users.  And a backup incremental potentially 16 generations deep.

As for restricting the FD.SEG's to 47, that would need more research. I 
did look once but did not find that define. From rbf.d there is no 
limiting define.  There should be.  Perhaps a new and as yet unused define 
FDSG.MAX equ 47 ?  And work from there.  But IIRC rbf does not track the 
actual FD.SEG number.  The relative lack of comments and proper names for 
its vars are a major pain in my a$$.   We need the real, original src's 
but I doubt they exist on this planet.

All of this of course means that EVERYONE will need to be using the new 
version, and we both know there are folks out there running the std 
distribution straight from the distribution media...  Mix & match=instant 
boom.  So, damned if we do & damned if we don't.

Another possibility might be to use the MSbit of the MSByte of the first 
FD.SEG, which if set would be beyond the end of the drive, until someone 
hooks up a 250Gb drive because no smaller ones are to be found.

Whatif's are fun, aren't they? ;-)
> 
> --
> Allen Huffman - PO Box 22031 - Clive IA 50325 - 515-999-0227 (vmail/TXT
> only) Sub-Etha Software - http://www.subethasoftware.com - Established
> 1990! Sent from my MacBook.
> 
> P.S. Since 4/15/14, I have earned OVER $600  in Amazon gift cards via
> Swagbucks! Use my link and I get credit:
> http://swagbucks.com/refer/allenhuffman


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS