Re: Need help with BSCit2.1 and changing file type

  To: macdog
On Tue, 10 Apr 2007 08:25:08 -0700, macdog wrote:

Yeah, I did that.  I had googled the file type and aux type and typed
in that info.  Maybe I have a corrupted file, or maybe Deliverance is
not making the changes correctly.  I'll start from scratch and try it
all over again.  If it still doesn't work, I'll attempt to re-download
the file and try it again.  At least I know I was using the correct

I'm thinking the original file is corrupt so retrying is probably best.

The only issue that just came to mind, is something I read
while googling that said not to shrink a bsc file.

I see no reason why you couldn't BINSCII encode a ShrinkIt file or
shrink a BINSCII file.  Doing either and undoing it should give you the
orginal file without any problems.  BINSCII encoding just takes 8 bit
data and converts it into 7 bit data for transmission over connections
that may only support 7 bit data.  ShrinkIt takes 8 bit data and
compresses it and stores it as 8 bit data.

However, shrinking a BSQ file, which is the usual extension given to
BINSCII files that contain ShrinkIt files, will result in that ShrinkIt
file being a little larger than the BSQ file and whoever gets that file
will end up having to unshrink the ShrinkIt file, unBINSCII the BINSCII
file and then unshrink the shrinkit file it contains which is kind of a
pain.  :-)

Shrinking a BSC file, which is the usual extension given to BINSCII
files that do not contain ShrinkIt files (and hopefully no other type of
compressed file), will result in a ShrinkIt file that is smaller than
the BSC file.  The same problem with multiple unshrinking/unBINSCII'ing
still exists though.  Better to shrink the file and then BINSCII it to
make a BSQ file if you need to transmit it over a 7 bit connection.

So I am wondering
that when I use bscit on the gscii.bsc file and it then shows up as a
gscii.shk after bscit works its magic, is this correct?  should it
automatically be changed to a shk file type?  I did not have any
options when I ran bscit, so I am assuming that what comes out is

I believe BSCit may automatically delete any BSC or BSQ file in decodes
successfully thereby leaving only the file(s) contained in it in the
directory so having gscii.bsc (which should be called gscii.bsq)
becoming gscii.shk is normal.

that I should just change the file type to LBR or $e0 and
the aux   to 8002.  I'll give another shot.  Thanks for the advice.

I'm pretty sure that BINSCII remembers the file and aux types of files
that it encodes.  It is possible that the original ShrinkIt file had the
wrong file/aux type to begin with.

BTW..the file associations are set up.....If i double click on any shk
file, shrinkitGS automatically launches.

The file type doesn't matter.  ShrinkItGS will happily open any archive
regardless of its file and aux type.  I believe the icon association
only matches the filename anyway (any file ending in ".SHK" or one of a
few other extensions).

If you are having problems with archive, ShrinkItGS should be telling
you the archive is corrupt.  If that is the case then there may be
something screwing up the BINSCII file during transmission.

Is there a particular reason you are using BINSCII files?  Most people
just use ShrinkIt files and if you want to preserve the file/aux type of
your ShrinkIt files then put a Binary II wrapper.  This is what a BXY
file is, a ShrinkIt file in a Binary II wrapper.  The Binary II wrapper
preserves the file/aux type and if you are null-modeming the file to
your IIgs then most Apple II communications programs can be set to
automatically strip the Binary II wrapper and set the file/aux types
correctly.  It is also possible to have Apple II communications programs
add the Binary II wrapper automatically and you can put Binary II
wrappers on any file, not just ShrinkIt files (but if you do, the usual
extension is .BNY).

Have I confused you enough yet?  :-)
--- Synchronet 3.13a-Win32 NewsLink 1.83 - Your total source for Apple II computing.