[Coco] Large file deletion fails on NitrOS9/6309

[Jeff Teunissen]

I'm aware of the 18 bits in the DAM for a bootable floppy; this is more
like thousands of them.

On Thu, May 28, 2020 at 12:28 PM Gene Heskett <gheskett at shentel.net> wrote:

> 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>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>