[Coco] Large file deletion fails on NitrOS9/6309

[Gene Heskett]

On Thursday 28 May 2020 22:03:27 L. Curtis Boyle wrote:

> 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 actually tested it at $FF, the only side effect was the DF message if 
there wasn't $FF free bytes at the end of the disk. Even a 1 byte file 
couldn't be saved.
 
> > 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.

No, it won't. When rbf is asked to save a file, it doesn't have a clue 
how big the files is so it looks for dd.sas free space, and if it can't 
find it, the file cannot be saved. If its a 1 byte file, it will take 2 
sectors, one for the fd.seg and 1 for that one byte, and then returns 
$1E bytes in the current cluster size to the FAT. But it must first find 
that dd.sas sized piece of disk.

> 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
> > --


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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>