[Coco] Large file deletion fails on NitrOS9/6309

[Gene Heskett]

On Thursday 28 May 2020 09:06:28 Robert Gault wrote:

> Jeff,
>
> Your problem may not be as straight forward as you think. I ran a test
> with MESS 0.158 and VCC on a file with 5,958,126 bytes and was able to
> delete it without any problems. The disk used was a .vhd with $5,A000
> OS-9 sectors. However, there was one small catch. :)
>
> The first time I tried to delete the file using MESS, the system
> froze. After rebooting, I was able to delete the file. I then did a
> DCHECK of the .vhd and found MANY clusters were in the map but not in
> the file structure.
> After correcting the allocation map, I was able to repeatably put the
> file back on the .vhd and then delete it without any problem.
>
> So it may be there is a problem with a system file like ioman or it
> may be that your disks had problems unrelated to file size that caused
> DEL to fail for you. Why don't you try doing a dcheck on a disk, copy
> your cococ.ar file to that disk, and then try to delete it. See if you
> still get the lock-up.
>
> Robert
>
> Jeff Teunissen wrote:
> > Deleting files that cross a $x000 cluster boundary seems to be
> > broken in the latest NitrOS9, and probably has been for a very long
> > time.
> >
> > I have an uncompressed .ar file, 'cococ.ar', that's about 3
> > megabytes in size. I use it to move up-to-date C source code from my
> > Linux system to my virtual CoCo hard disks. When I delete the
> > archive from the disk, the system mostly locks up -- that is, the
> > "delete" command never finishes and no programs can be run, though
> > things like CLEAR to change windows still function normally.
> >
> > When I issue the command "del cococ.ar", the directory entry is
> > marked deleted as expected, and the allocation map is updated...but
> > it seems to stop updating the disk allocation map at the next $x000
> > cluster boundary.
> >
> > On the disk, the file starts at cluster $189C and goes all the way
> > to cluster $5A80, and is referenced in LSNs 4-12. The deletion
> > succeeds up to the end of LSN 4, which describes clusters
> > $1800-$1FFF, and then nothing further works.

Jeff should also be aware that dcheck has never learned to ignore boot 
tracks and there will be 18 sectors in the allocation map that are not 
in the file structure, unless he has also previously executed my 
krnl-to-dir.b09 utility.  It generates a dir entry and a FD sector that 
accounts for the boot track on track 34. In that event, you will have a 
directory entry "KERNAL", miss-spelling intentional in the root dir of 
that disk or disk image.


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>