Re: what are .sdk archives?

["Michael J. Mahon" <mjmahon@aol.com>]

David Empson wrote:
> <touchstone> wrote:
>
>
> > On 2007-12-26 17:01:11 -0700, dempson@actrix.gen.nz (David Empson) said:
> >
> >
> > > Michael J. Mahon <mjmahon@aol.com> wrote:
> > >
> > >
> > > > Michael Kent wrote:
> > > >
> > > > > To: touchstone
> > > > >
> > > > > > i give up!!
> > > > >
> > > > > > thanks everyone for their input on this, but i simply cannot get an
> > > > > > unforked file transfered from a mac.
> > > > >
> > > > > If you have access to a IIgs -- perhaps through emulation -- ShrinkIt GS
> > > > > can handle the .sdk archives directly, and it will handle forked files
> > > > > just fine.  You could then re-archive the disk or files into a different
> > > > > format if you have to.
> > > >
> > > > And once you get UNFORKIT working (which is actually a pretty small
> > > > Applesoft program), you can easily access everything else.
> > > >
> > > > Have I mentioned how much I wish the Mac would not add forks to
> > > > files that don't have them?  ;-)
> > >
> > > It doesn't.  The only reason a Mac will add a resource fork to a file
> > > which doesn't have one is if you do something like add a custom icon to
> > > the file. It is perfectly OK to have a file on the Mac with a data fork
> > > and a zero length resource fork.
> >
> > the mac is not adding a macintosh resource fork.  although prodos is
> > claiming that a forked file exists, while it may, it is not refering to
> > the macintosh fork. the forked prodos archivew i was working with had
> > resource forks of zero k, and would only add the fork if i asked the fork
> > editor to add one.
>
>
> The key issue is that ProDOS-8 doesn't support a file with the
> "extended" storage type.

This is, of course, correct--a pox on the designer who even made
such a choice representable in the ProDOS environment!  Let those
who need forks use HFS!

It is only an imprecise (but understandable) expression to refer
to a ProDOS extended file as a forked file.  However, the error
message delivered by 8-bit ShrinkIt is that it cannot open a
"forked file".

For one who inhabits the 8-bit Apple II world, extended/forked
files are inconvenient at best and useless at worst.  It is
reasonable to refer to a file rejected as being "forked" as
a "forked file" even though its non-data fork is null.

> A standard ProDOS file (storage type of sapling, seedling or tree) has a
> directory entry which points to a single data bock (sapling), single
> index block (seedling), or second level index block (tree).
>
> An extended ProDOS file (supported by GS/OS and the Mac) adds an
> extended key block between the directory entry and file data. The
> extended key block contains two partial directory entries to define the
> data fork and resource fork of the file (either of which may be empty,
> or a seedling, sapling or tree), plus it can store extended information
> about the file, which is used for Mac-specific directory information.
>
> Anything claiming that a file is "forked" on ProDOS-8 might be
> misleading. It really means the file is extended, which might or might
> not have a resource fork.
>
> The extended storage type and extra block are sufficient to prevent
> ProDOS-8 from doing anything useful with the file (short of third-party
> utilities which do block-level access to the volume).

And this is why I wish that MacOS did not create such files by default
when it doesn't know the type of the file.

Perhaps someone in Mac-land envisioned a world in which 8-bit Apple II's
would be happily juggling ProDOS extended file types--or maybe they just
thought of ProDOS 16 and forgot completely about the myriad users of
Prodos 8.

Adding the extended type to the ProDOS file system was a silly thing
to do, since it breaks every 8-bit utility, sometimes in a "silent",
data-corrupting way.

It would have been perfectly fine for MacOS to default the type of an
"unknown" file to TXT, and any 8-bit application could have easily
interpreted the content of the file or copied it, etc.  The worst
thing that could have happened is that someone could have attempted
to view it or print it as a TXT file, and seen gibberish or screen
weirdness.  ShrinkIt, and every other application that looks inside
a file to assess whether or not it is compatibly formatted, would
have been perfectly happy.

As it is, choosing the default of "extended" (or NON) makes the file
essentially useless for anything in the 8-bit world--until the very
inelegant program UNFORKIT (there's that word again ;-) converts it
back into a non-extended file with a less useless type.

At the very least, ProDOS 8 should have had a new command added to
allow converting "extended" files with empty "extensions" to be
safely re-typed and the directory entry and available space table
properly mended.

If any MacOS designer had ever tried to move untyped files to ProDOS
s/he would have quickly discovered that defaulting to "extended" type
was not the correct choice in the sense of maximizing the utility of
the file.

Defaults are *always* a problem, and designers should choose them
with an eye to 1) preventing disaster, and 2) maximizing utility,
even though both objectives can often be only imperfectly achieved.

-michael

NadaPong: Network game demo for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."