Re: what are .sdk archives?

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

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.

Some utility software on the Mac might do something silly like create a
resource fork header when there is no need for it. The resulting file
will always be extended if copied to ProDOS.

The other (and most common) reason for the Mac creating an extended file
when copying to a ProDOS volume is to preserve the Mac-specific
directory information (Finder Info, including the filetype and creator).
This is not the same thing as a "resource fork".

You can minimise the chance of bumping into extended files by setting
the Mac creator to 'pdos' and filetype to 'TEXT' (or something else
suitable - see below) before it is copied to a ProDOS volume.

There might be other data in the Finder Info which the Mac thinks is
important enough to retain: icon position and various flags. The
relevant flags for files that might be copied to a ProDOS volume (and
has a zero length resource fork) seem to include: label colour,
stationery, name locked, invisible.

This suggests that any of the following actions on a file destined for a
ProDOS volume might result in that file being extended:

- Already has a non-empty resource fork, e.g. a custom icon.
- Creator is not 'pdos'.
- Filetype is not something which can be represented on ProDOS (see
below).
- Icon has been dragged to a specific position within a folder (or on
the desktop) in Icon view. (Default positioning shouldn't cause a
problem, and neither should List view.)
- User has set a label colour on the icon.
- User has set the stationery flag in Get Info.
- Filename has been locked (tricky to do).
- File is invisible (tricky to do).

ResEdit's Get File Info command can access the Finder flags and adjust
them. It should also reveal whether there is already a resource fork and
allow setting the filetype and creator. I'm not sure if it can do
anything about the icon position.

The valid filetypes include the following:

'TEXT' (maps to TXT)
'04  ' (also maps to TXT)
'06  ' (maps to BIN)
'FC  ' (maps to BAS - AppleSoft BASIC)
'FF  ' (maps to SYS)

Any other two hex digits followed by two spaces will map to the
corresponding ProDOS file type, with a zero auxiliary type.

To represent a filetype and nonzero auxliary type you need to be able to
enter 8-bit binary characters which many of the Mac filetype editing
tools don't support. A Mac filetype starting with a literal lowercase
'p', followed by the filetype (8-bit binary) and auxiliary type (16-bit
binary) will map to the corresponding ProDOS filetype and auxtype.

-- 
David Empson
dempson@actrix.gen.nz