[Coco] Question for those familiar with rbf.mn

[Gene Heskett]

Greetings;

20 years ago I thought the program backar was a good idea as it could walk 
thru the system, backing up ONLY those files and dirs that had been 
changed since the last backar run.

Doing backups in nitros9 has been a bit of a cross between watching paint 
dry and grass grow, painfully slow. When you have about 100 megs, expect 
to be swapping floppies on demand, 24 hours a day for at least 3 days, and 
to recover (I did that once with BRU1.2) takes at least a week even with 
the interleave adjusted to optimize the write time down to nominally 8 or 
9 minutes an 80 track ds disk.

At the time I used the backar authors tally scheme by setting or clearing 
a bit in the last, 48th, fd.seg, thinking no one would ever hit a file 
that badly fragmented or big enough.  By then I had been campaigning to 
get folks to raise the default value of it.sas in their rbf file 
descriptors from $09 to at least $10, and I was using from $20 to $FF in 
order to assure both non-fragmented files, AND at the same time prevent 
ever coming close to a segment list full error because if you do, 
nitros9's recovery from isn't pretty.

So I have recently been looking over the FD Sectors defines, looking for 
some place else to store this "I am still the same as when last backed up 
bit, so skip me this time."

On inspection of the rbf.d defines. it shows that FD.OWN is an integer.
I personally, because I am the only one who has used this machine from day 
one, or was present when the wife did a report card on it, do not have a 
single file that I am aware of that is not owned by 0, effectively root I 
guess.

Therefore I have no clue what happens if I fire up ded and change a nibble 
someplace in the 4 nibble wide assignment to a non-zero status but I 
intend  to find out.

If such a re-assignment of function was done, there are probably a few 
places in the kernel, and in utility's such as dir -e to insulate them 
from interpreting a high bit as being an excuse to deny user 0 from 
accessing it.  Fallout if you will. And of course fixable when found.

=========
So my question to all is:

Do you in fact, have anything, anywhere on rbf managed storage, that a  
dir -e reports as the owner being non-zero?
=========

These are the 2nd and 3rd bytes of the FD.SECTOR, shown as integer, and I 
propose to redefine that integer as two bytes, the 3rd staying as owner, 
which can still account for 255 users,  but the second byte becoming a 
backup level counter.

My grepping thru the sources in the L1/cmds dir seems to indicate that his 
integer is hard coded to $0000 by format for the root directory of the 
medium, but I believe it is possible that someone actually logged in via a 
seriel port terminal, who actually "logged in" using tsmon & login could 
possibly have a non-zero owner number. IDK myself as I start a shell on 
/t2, and access it with an invocation of minicom on this linux box.  The 
minicom session is not capable of doing anything but plain text because 
the control chars are not properly translated.  That of course is my 
problem and not germane to this question.


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