Re: what are .sdk archives?

[mdj <mdj.mdj@gmail.com>]

On Dec 29, 5:30 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:

> > 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!

A bit harsh perhaps - there are other storage types (Pascal areas for
example) that ProDOS utilities correctly avoid, and leave up to the
'owners' to deal with. It's a feature, not a flaw.

> 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.

LOL, it's certainly a "forking" mess ...

> > 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.

I'd much prefer anything unrecognised be BIN ...

The mentioned utilities work well for what they were designed for -
principally being shifting AppleWorks and ASCII files back and forth.
The biggest issue I have is ProDOS's view that Filetype $00 (untyped)
being treated as 'bad' was tremendously shortsighted (and/or arrogant)
on the designers behalf. Perhaps we can blame the Apple III design
team for that :-)

As for 'forked' files, post Apple IIgs (8-bit) system software should
have dealt with such files gracefully. It's the responsibility of any
system with a 'wacky' metadata system to handle foreign content, not
vice-versa.

I see such problems as a microcosm of a much larger issue which the
industry is only just beginning to deal with.

Matt