Re: Facelift and BXY

[CUTjefbla@bconnex.net (Jeff Blakeney)]

On 11 Dec 1997 03:21:09 GMT, nathan@visi.com (Nathan Mates) wrote:

>   And if you add the comment with GSHK, it's not in the resource
>fork, and can be uploaded without getting lost. [Heck,

But then you can only read the comment if you open the archive.  As a
Finder comment, you can read it from in the Finder.  I like the idea
of using either the finder comments or rBundles to list the version
number of files and it would be nice to have this with archives.  This
way you could get more information without having to open the archive.

>FinderComments(tm) destroy the possibility of you being able to upload
>from a ProDOS 8 app like ProTerm, so I'd think the marginal benefits
>of them for .shk files is dubious at best.]

Here is where things might get tricky.  Yes, having a resource fork
does limit you to not being able to upload the file with a P8 program
but if you are using a IIgs, which is the only way you could have
created the resource fork, you should be able to upload it from a
GS/OS program such as Spectrum.  This would wrap the extended file in
a Binary II wrapper.

Now, it is at this point I'm not sure what will happen because I
haven't tried it.  If someone downloads this file with a P8
communications program then one of four things will happen:

NOTE:  References to the comm program and ShrinkIt are to a P8 comm
program and the P8 version of ShrinkIt.

1) The comm program doesn't support auto binary II unwrapping so the
file will be written to disk with the Binary II header and will still
be usable by ShrinkIt.  The comm program can re-upload this file.

2) The comm program supports auto Binary II unwrapping but sees that
it contains an extended file and knows that it can't unwrap it so
writes the file to disk with the Binary II header.  This will still be
usable by ShrinkIt.  The comm program can re-upload this file.

3) The comm program supports auto Binary II unwrapping and sees that
it contains an extended file and manually writes the data and resource
forks to disk.  This will NOT be usable by ShrinkIt as it will have a
resource fork.  The comm program CANNOT re-upload this file.  I also
don't believe that such a P8 comm program exists so this probably
won't happen.

4) The comm program supports auto Binary II unwrapping and sees that
it contains an extended file so writes the data fork and resource fork
to disk as separate files.  This data fork file will still be usable
by ShrinkIt.  The comm program can re-upload the actual archive
without the resource fork.

So as you can see, it shouldn't matter whether it is there or not.
The only case where it wouldn't work is number 3 and I don't think
there is a single P8 comm program that actually does that with the
possible exeception of ANSITerm but it only runs on a IIgs.

But still, Binary II also preserves the filetype, auxtype and creation
and modification dates and times.  These I find very useful as well
especially when comparing archives of two different versions of a
program.  The one with the newer date should be the newest version and
not just the last one I downloaded.

The only time I find Binary II gets in the way is when sharing data
with non-Apple IIs.  And even then, you just need to remove the first
128 bytes to get rid of it.

=== I've had enough SPAM.  Cut the obvious from my address to email me. ===