#: 13693 S10/OS9/6809 (CoCo)
    26-Dec-91  11:11:36
Sb: #13692-#NEW RBF PATCH
Fm: Bob Santy 76417,714
To: Kevin Darling 76703,4227 (X)

Sure enough guys!  The problem was that the FD was being saved BEFORE the link
count was decremented and therefore the link count NEVER got decremented on
disk.  I've fixed the problem with the disk based link count.

After the FINAL delete, the link count is now (RBF version 30) zero on disk.
The problem with that is the UnDel command had to be changed to make the link
count on disk a non-zero value.  I used one.  I think that will work just fine
since we are un-deleting the file and restoring it to base condition.  So,
we'll need a new RBF (Version 30) and a new UnDel command. I'll upload them
ASAP if I can get some answers to the following:

1. The file is ALWAYS removed (1st byte of the name set to null) from the
directory REGARDLESS of the link count.  If the link count of a file is greater
than one and the file is deleted (I$Delete), the file name is gone but the
space is NOT returned.  One hopes that the file is still opened (presumably by
some other process) so that the link count can finally get to zero and the
space recovered.

2. I ran into the infamous B.L.O.B. during testing of RBF.  It seems that if
CC3Disk is NOT loaded at an ODD address, the floppies will act very strangely. 
Now, that's MY version of CC3Disk and it's in my bootlist right after RBF.  If
RBF (at an even address) was an even numberof bytes, CC3Disk was intermittent. 
I added a NOP to RBF and CC3Disk was OK.  Any other possible explanations?  Doe
the floppy interrupt handler have to be at an ODD address??????

I'll be waiting for more discussion before I upload.

P.S.  Last time I tried to upload a file to the data libraries, I got the
message that they were full.

Bob Santy

There is 1 Reply.