[Coco] Question for those familiar with rbf.mn

[L. Curtis Boyle]

It would, however, break things for people that deal with files large enough to use all the segments (and we hit that a few times at work - and our default allocation was original $80 sectors/cluster; we later bumped it up to $ff to avoid such things.
We also had about 15 local users, and also some remote users for uploading files, although I don’t remember the grand total).
The safest ways to keep track of this, I think, without breaking anybodies unique circumstances, is to either create a separate file listing all files with last backed up dates (would be easy to hand edit if things went wrong, or if you want to override a file being/not being backed up, but probably pretty slow to search through). You could save space by only saving the sector number to each file entry, along with the timestamp, which would speed up searches, but modifying it by hand would be much more involved.
I do remember using a backup utility called STREAM (I think), that was fairly quick - we could back up an entire drive in one night. We also used the special FORMAT command that did 20 sectors/track (and 82 tracks on a 3.5” 720K drive, since it handled it), which gave us close to 820K per floppy. Even leaving it at 80 track gave 800K per floppy. 
 
L. Curtis Boyle
curtisboyle at sasktel.net



> On Feb 1, 2015, at 7:53 AM, Allen Huffman <alsplace at pobox.com> wrote:
> 
>> 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 :)
>