[Coco] Large file deletion fails on NitrOS9/6309

[Jeff Teunissen]

Yeah, that's one of the failure modes of the broken deletion, leaving lots
of allocated sectors behind. I have repaired DAMs several times
specifically because of this particular version of "can't delete this big
file"

I have noticed that when it fails in that particular manner, the sectors
that are left allocated seem to always map to the start of a sector in the
disk's allocation map -- as if RBF or IOMan were able to rewrite all the
bytes in the previous BAM sector, but failed to move on to the next and
crashed there.

On Thu, May 28, 2020 at 9:06 AM Robert Gault <robert.gault at att.net> 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.
> >
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>