[Coco] Another Coco Virtual Disk Util

[Walt Zydhek]

I am wondering if the difference in free space might be related to directory
space. I might have misunderstood the OS9's process. In my code, when a new
directory is created, 8 sectors (plus file descriptor sector) are allocated.
When those 8 sectors are full, any additional directory entries results in
another 8 sectors being allocated for the directory. For files, Only the
necessary number of sectors plus the file descriptor sector are allocated. I
wonder if these methods are causing the problem. I need to delve deeper into
the issue.

As for when it stalled when you were trying to drag/drop, the only thing I
can think of is that there was an error during the drop that I haven't
accounted for, so it wasn't trapped and stalled out.

I just did a test. Created a new vhd. Noted the freespace, root copied from
another vhd made by someone else (Users Groups - ROTD - Sierra Online
Archives.vhd), noted the resulting freespace (which was more available that
the source vhd), Deleted everything from the new vhd instead of formatting.
The resulting freespace matched the formatted freespace.

I then took a copy of that 3rd party vhd, deleted all files (instead of
format) and it has the same amount of freespace as formatted. So there is
definitely an issue in the copying. I will add that feature of number of
files and directories (and sum of file sizes) and show that in the status
bar.

-Walt Zydhek

-----Original Message-----
From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] On
Behalf Of Wayne Campbell
Sent: Monday, October 21, 2013 1:58 PM
To: CoCoList for Color Computer Enthusiasts
Subject: Re: [Coco] Another Coco Virtual Disk Util

I have more info on EmuDisk. The drag-root to copy disk didn't work. Below
is my description:

What I did (all in EmuDisk):
Create a new vhd image.
Format the image.
Drag each file in the root dir of the source image to the new image.
Drag each directory in the root dir of the source image to the new image.
I did not copy sub-dirs above the root level separately.
I let EmuDisk handle the sub-directories.
Source image free capacity (in BYTEs): 89196800 New image free capacity (in
BYTEs) after all copying is done: 89308928

  89308928
 -89196800
  ========
    112128 BYTEs free that aren't free on the source image.

When I tried dragging the root directory to a freshly re-formatted image, I
got the Importing dialog, but nothing ever appeared as being copied. After
about a minute I closed the Importing window and the destination image and
then re-opened the image. It was as though I never tried to drag anything.
I do not know what that is about, and I can't say the two things are
related, because the source image may have allocated sectors in the FAT that
aren't really being used anymore. I've seen it on every hard disk I've ever
looked at the file structure on. They all get that way and after a time you
have to re-format just to reclaim the lost space.

What I could use is for EmuDisk to tell me how many files are in each
directory (not including '.' or '..'). It does not have to account for files
in sub-directories in that directory, but a count of files and
sub-directories in that directory, and total of both would be sufficient for
each directory or sub-directory on their own.

Wayne

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco