Re: hfs files

[Randy Shackelford <shack@onyx.southwind.net>]

Jeff Blakeney <CUTblakeney@home.com> wrote:

:>Sorting directories is a non issue since HFS directories are B trees and
:>file entries are always alphabetical. The rest are easy to get around
:>if you have a Mac with Norton handy.

: Ick.  It is a good thing that we can't use HFS to boot otherwise we'd
: have to rename all our inits if we wanted to load them in a certain
: order.

Well Macs deal with it ok. For some extensions which must load first, such
as CFM-68K, they put a space at the beginning of the name. That moves 'em 
up to the front alphabetically.

:>It could be tied to volume size. I have a 200 mb HFS volume and the speed
:>is acceptable.

: See my reply to Supertimer.  It would seem that a system add-on I
: recently removed was causing the problem.  Which one, I'm not sure.
: Things seem to be working much better now.

I never thought the speed was all that bad, not blazing fast either of course.
I expect it's due to the variable block sizes and B tree directories. I'd
figure there's more number crunching there.

:>It would require an entire new file system since so much stuff in ProDOS
:>is hard coded to 32 mb volumes.

: There are a number of places that block numbers are stored as 2 bytes
: but changing that to 3 bytes and modifying the existing code to use 3
: bytes isn't an insurmountable problem.  Allowing files larger than 16
: MB and allowing longer filenames with less naming restrictions would
: start to get a little more difficult, though.

Keep in mind that HFS has a limit of 65536 blocks/volume just like ProDOS
does. It supports bigger volumes by changing the block size. HFS+ finally
did away with that restriction, but the file systems are considerably
different.

Removing the 16 mb file size limit would be easy in part. You'd just define a
super-tree storage type, which has a master-master index block which points
to multiple normal tree style master index blocks. Then you'd have to have
extended files be able to support super-tree forks. The problem comes where
there's only three bytes to hold the EOF. That only allows 16 mb. But if you
could do it somehow, this wouldn't buy you much with a 32 mb volume limit in 
place of course. 

Filenames would require redefining the directory format, which is tantamount
to making a new file system.

: Personally, I'd be happy with just larger volumes sizes.  Other
: improvements would be nice but I can live without them.

:>I'd lean toward making HFS utilities and,
:>if people were to reach the point of writing FSTs, making a faster HFS.

: Regardless of whether we get larger ProDOS volumes, I think it would
: be nice to have HFS utilities.  Sure would make my IIgs that much more
: flexible.

If someone would write 'em and make 'em freely distributable, I'm for that.
Otherwise it's too easy to connect the hard disk to one of the Macs on
hand and use Norton.

:>There would be no point in making a new file system which no other platform
:>could understand when there's a perfectly good (and interoperable) system
:>already around. Plus that could be easier to implement than an FST for an
:>entirely different file system.

: Having a simple, reliable, fast, optimized file system would be a good
: thing in my opinion.  GS/OS is really nice in that is allows us to use
: multiple file systems.  If file sharing with other machines is a
: concern, make sure you have a drive or at least a partition formatted
: for use with other machines.  Personally, in the case of sharing with
: a Mac, I think it would be easier to set up a network and do file
: sharing that way.

That's what I'm in the habit of doing. I think using ProDOS and HFS together
gets the job done, and only speeding up HFS access and having disk maintenance
are necessary.

: The way I see this FST project is that extending the capabilities of
: the ProDOS FST, either by patching or creating a new FST, is just a
: learning process.  Once we can do that, then we can turn our attention
: to fixing the bugs in the HFS FST, making the MS-DOS FST read/write
: and support FAT32 and long filenames and maybe even allow us to create
: NTFS or unix FSTs as well.  I see it being a good thing all the way
: around.

No argument there
-- 
Offsite mail to this host gets nuked.