Re: :( 12 Partition Limit!?!?!??? :(

[nparker@cie-2.uoregon.edu (Neil Parker)]

In article <4rneci$e6s@nnrp1.news.primenet.com> johnlb@primenet.com (John
Bowling) writes:
>In article <4rn97o$e2i@atlantis.atlantis.actrix.gen.nz>,
>David Empson <dempson@atlantis.actrix.gen.nz> wrote:
>>[...]
>>The best method of handling a large hard drive would be for someone to
>>write a utility that patches ProDOS's internal tables to select between
>>arbitrary 32MB partitions on a large hard drive (or drives).  You
>>could then remap any ProDOS partition to any unused ProDOS unit number
>>(probably still excluding real devices, to avoid confusing software
>>that tries to work out what device it is talking to).
>
>I can see another problem when you are trying to write out a file that
>fills the partition and then need to use part of the next one.  The
>next block address would put you back to some place in the current 
>partition (probably in the middle of another file).  It would take some
>extra manipulation to find out where the continuation of the file is.

This wouldn't be a problem.  Presumably any partition-switching utility
would only switch in valid ProDOS paritions.  A valid ProDOS partition
contains, among other things, a field in its volume directory that indicates
what the maximum block number of the partition is.  Any attempt to allocate
blocks after that limit will fail with a "disk full" error...that is,
there's no danger of "block wrapping," or of accidentally using a block
that belongs to another partition (unless the paritition table or the
volume directory is corrupted).

>It would be best if the FST would look at the size of the file and the
>space remaining on the disk and then jump to the next partition if
>needed to keep the file on one partition.  And there are times when the
>size of the file is unknown.  An example is while editing and you have
>saved when partially completed, and then go to save needing more space
>than is available.  This would require that the current file be deleted
>before the next one is saved.  I suspect most editors simply write the
>current data out to an already open file, and the new process must
>work with all existing software.

If you want a file that's too large for the remaining space on one
partition to be automatically moved to another partition, there are several
difficulties that stand in your way.  First, you have to know how big the
file is going to be when you create it.  This information *may* be available
under GS/OS, if the application program chooses to provide it, but is
*never* available under ProDOS 8.

Second, you have to know that another parition with sufficient room for
the file is available.

Third, when the file-remapper is done, the file won't be where the user
expected it to be--in fact, it may end up on a completely different disk
drive.  The mind boggles over the potential for confusion.


If you want a file that overflows a parition to be continued on another
partition, so that part of the file is on one partition and part is on
another, then the difficulties are even worse.  In addition to the problem
of locating a second partition that's guaranteed always to be available
when the first is online, you have to worry about how to flag the fact that
the file has a continuation.  I can think of two ways to do it...one would
be to put a flag in the split file's directory entry that says it's
continued on such-and-such a parition, and the other would be to attach a
flag to the block numbers that says "look in the other partition for these
blocks."  In both cases, there's no room in the ProDOS disk layout to save
the necessary information.  You'd have to write a new (ProDOS-incompatible)
FST to do it, and as long as you're going to all that trouble, you might as
well just write an FST that doesn't have a 32-megabyte limit in the first
place.

              - Neil Parker
-- 
Neil Parker, nparker@{cie-2,cie}.uoregon.edu, http://cie-2.uoregon.edu/~nparker

     "Evolution is vastly overrated."  -- Ambassador Delenn, _Babylon_5_