Re: Going past the 51 file limit, other than GEOS?

[shack@southwind.net (Randy Shackelford)]

In article <38c834f5.110787257@news>,
Jeff Blakeney <CUTblakeney@home.com> wrote:
>
>>Ah, so it grows the root directory in the same manner as subdirectories.
>>I don't think this is a very good idea - a fragmented root directory on
>>a 5.25" disk (in particular) is not a good thing.  A better plan would
>>be to create the root directory as a contiguous chunk, with a larger
>>fixed limit, at the point the disk is erased or formatted.

I experimented with a block editor a really long time ago, using it to add
blocks onto the volume directory. I just used block 7 for the next block,
then block 8, and so on. That saved me the trouble of moving the bit map
off block 6. All software, rather it reads the directory as a file or 
does its own block reads following the links, could cope with skipping
block 6. But the EOF of the volume directory is fixed at $800, and there
is no increasing it since it isn't stored anywhere. With subdirectories,
it's stored in the file entry, and is $200 times the number of blocks the
directory uses.

I'd have to whip up some code to check, but I imagine disks with nonstandard
volume directory sizes like the Appleworks program disk and the 64K RAM disk
still have $800 for the EOF. Well maybe not the RAM disk since its driver
does plenty of nonstandard stuff. In any event, most software worked on my
hacked experimental disks. Copy II Plus gave a premature EOF when I did
catalog, can't remember if anything else choked.

>I used to think that Apple was being pretty silly making the root
>directory a fixed size seeing as sub-directories aren't limited in
>this way.  After thinking about it for a long time, it seems to me
>that by doing this they made it easier for them to write the boot
>block code to find the PRODOS file and to write the PRODOS file's code
>to find the first *.SYSTEM file.  This is because those pieces of code
>know that they only have to look in blocks 2, 3, 4, 5 as those are the
>only directory blocks in the root directory.

At least early on, ProDOS was designed with support for future capability.
That came in the form of the version and min_version file entry fields. Those
fields were reassigned, but they show that the intent was to support changes 
in the file system. So I doubt any such hard coding was used. The boot block
does block reads following the links in the volume directory header to look
for a file named PRODOS, I expect. Ditto when ProDOS looks for a file named
.SYSTEM to load.

>Extending the root directory could cause problems if PRODOS or the
>*.SYSTEM file are not in the first four blocks of the directory.  It
>just means that the disk will give you a message saying it can't find
>PRODOS or a SYSTEM file when you boot it but it could definitely have
>you scratching your head for a while trying to figure it out.  :-)
>
>However, if people do want to extend their root directory (which I
>also don't see much need for), they should also patch the boot block
>and PRODOS so that they will search the entire directory for the
>appropriate files as well.

As I said, I doubt that's the case. Wouldn't be hard to verify though.
--
Offsite mail to this host gets nuked.