[Coco] Large file deletion fails on NitrOS9/6309

[L. Curtis Boyle]

On May 28, 2020, at 7:50 PM, Gene Heskett <gheskett at shentel.net> wrote:
> 
>>>> 
> One other thing I should point out as this conversation is refreshing my 
> memory a bit, is the segment allocation size (DD.SAS) in the disk 
> descriptor, which may, for old installs, still be set at 8 which does 
> allow all 48 segment 5 byte entries, 24 bits for offset start, and 16 
> bits for length, to be used.  There is no recovery for that, never has 
> been, probably never will be.

In EOU, we left SAS as 8, but on the hard drives, its set to $80. We hit problems with it too low at
work all the time, since we regularly used multi-megabyte files. (Actually, at work, we use $FF).

> 
> I submitted a patch that expands that DD.SAS to $20 (32 decimal) sectors 
> as insurance of never hitting the end of that 48 segments because if you 
> do, its blowup time. Use dmode to check that, and or fix it if yours 
> hasn't been corrected to $20. Do it NOW. The only side effect will be 
> the inability to use the last 31 sectors of a floppy.
> 
> But what size is that set to in the toolshed disk code?  If it is still 
> using 8, there quite likely is your problem. When set at $20, but the 
> file does not use that $20, rbf gives back at the end of the 
> transaction, all sectors that are not actually used. But you cannot play 
> mix-n-match with the DD.SAS, it must be consistent across all software 
> that can access that storage media.  And of course if toolshed is 
> cluster size sensitive, that must also match what the disk (or file) is 
> formatted to. I don't know that toolshed is cluster size sensitive.  Its 
> possible it is not. I've never kicked its tires as its newer than when I 
> worked on rbf, and after a pulmonary embolism several years ago at 79 
> yo, I am not capable of doing it today at 85 yo. Those things, with a 
> 98+% fatal rate, are hard on the IQ.  There are folks here who could, 
> but I'm sadly no longer in that group.  Now its up to the newer 
> generaion of coco/nitros9 fans here to find this one and fix it.
> 
> Obviously toolshed's version of dd.sas should be checked, and if not 
> fixable, disabled from ever working with os9 formatted media. Or 
> disabled if cluster sizes don't match.  Thats 2 conditions it should 
> check for.
> […]

I honestly don’t think the SAS setting is relevant in Toolshed. In RBF, SAS is used as the minimum number
of clusters/sectors that it looks for to be empty and contiguous, but it will fall through to using less if that is all
that it can find. SAS is a tool to reduce fragmentation (another way, if you know what size the file you are
creating will end up being, is to pre-extend the file to it’s full size first, then fill the file in with data). Toolshed is
definitely assigning more than $800 sectors/clusters per segment, and that is overflowing RBF’s internal buffer
for handling the bitmaps.
(These files can be fixed after the fact on the Coco side, however - a quick utility to expand the single segment entry
to as many entries as needed, and making each entry’s start offset picking up where the previous left off, will fix
such files to be compatible with RBF (as long as you stay within the 48 segment/24 MB limit).
Bill Nobel will be looking into seeing if we can “fix” RBF to work with a partial cache of a large file's BAM, so that
it can handle one sector’s worth at a time. We have to be careful with disk locks, though, so that it makes sure that
it has blocked off access to ALL of those sectors needed, so that another process can’t come in and change things
before the original process deleting the file knows what is happening.


> 
> Cheers, Gene Heskett
> --