Re: Disassembling an FST...(what about FAT?)

[dempson@actrix.gen.nz (David Empson)]

Jeff Blakeney <CUTjefbla@bconnex.net> wrote:

> On Mon, 21 Sep 1998 22:42:38 +1200, dempson@actrix.gen.nz (David
> Empson) wrote:
> 
> >Supertimer <supertimer@aol.com> wrote:
> >
> >> What about FAT?  If the MS-DOS FST was read/write and GS/OS
> >> was installed on an MS-DOS volume, could GS/OS boot from it?
> >
> >Not if the disk was also able to boot a PC.  The boot code for the IIgs
> >and PC would need to be in exactly the same place.
> 
> Umm... Why would you want to be able to boot a hard drive which
> contains GS/OS and Apple II software, from a PC?

A ZIP disk, perhaps?  No, that doesn't seem likely either - just use two
disks.  (And what proportion of PC-based ZIP drives can be used to boot
the machine anyway?  Practically none in my experience.)

Some MS-DOS utilities might not like the volume if it doesn't have
something that looks like PC boot code at the beginning of the first
block.

> >For starters, FAT has no concept of forks.  The Mac has to use an ugly
> >hack (a hidden subdirectory containing the resource forks) to get around
> >this.  Most of the file attribute options are missing, and there is no
> >way to store a file type without some kind of auxiliary file (as with
> >the Mac using FAT).
> 
> Easiest way around this problem is to use an Apple invented file type
> called the AppleSingle format.  It just puts both the data and
> resource fork into one file with a wrapper, I believe.

Hm.  Imagine trying to implement the simple operation "increase size of
data fork by one byte".   You would have rewrite any data which followed
it (presumably the resource fork).

AppleSingle is intended for archival storage or transfer of a Mac file
through a foreign file system, not for maintaining the file while it is
on that file system.

It would be fine for files that never change.

> The only thing with this method is that is would require an add-on driver
> to GS/OS to allow you to access the data or resource fork from such
> files.

GS/OS doesn't support the concept of an "add on driver" in this context.
You can't have nested FSTs either.  (I'm assuming we aren't considering
major architectural changes in GS/OS, just hypothetical modifications to
existing FSTs given the source code.)

> Basically, it would have to work something like AutoArk or HardPressed to
> support on the fly unwrapping.

I can't see this happening at the FST level without some messy
internals, effectively implementing a two-layer FST, with a high level
virtual file system over the low level real file system.

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand