Re: Kegs and HFS

[supertimer@aol.com (Supertimer)]

phoenyx <phoenyx@texas.net> wrote:

>Here's a few more tidbits I picked up while testing
>this HFS volume.

Hi Phoenix, thanks for your efforts.  It seems I really have to get
Linux for my PC now.  ;-)

Before this, I had no motivation to get it.  After all, it is true most
of the software is either cheap (like Linux WordPerfect) or free
(like Linux Netscape), but there are so few titles.  But when it
comes to my IIGS stuff, it is worth it!

>  o  Files copied from the drive automatilly lose their
>      filetype. This is to be expected since the destination
>      system doesn't track that info.

It might seem that way from the Linux side of the fence.  Under
GS/OS, the HFS FST stores the IIGS file type and aux type in
a different way than a Mac does.

To test this, try copying a IIGS file of known file type from a
ProDOS volume to your HFS volume.  Now from the IIGS Finder,
select "Icon Info."  You see that the file type is still correctly
identified.

I do not know what would happen if you try to copy the file
around from the Linux side.  Maybe the IIGS file type will stick.
Maybe not.

>  o  SHK/SDK files copied from then back to it will have
>      a filetype of zero but Shrinkit and Shrinkit GS opened
>      them successfully.

Probably Linux did this...not sure how to avoid it.

ShrinkIt! GS is designed to open a file regardless of file type,
so this is safe.  However, losing the file type (not to mention
the resource fork) would render a IIGS application file unusable.
This probably means IIGS application and data files cannot
be touched from the Linux side.

>  o  The same applies to a GSCII file (binscii gs) the file
>      transferred back and GSCII converted it successfully
>      to a valid SHK file replet with filetypes and all.

Yup.  GSCII and ShrinkIt! GS were designed to function this
way because PCs usually lose the file types.

>  o  Transfers between HFS volumes work fine!

Now this is interesting.  Are you saying that copying a IIGS
file from the Linux side and from one HFS volume to another
does NOT lose the file type?  That's great news!

>With this information I am considering changing the files
>on my site to gscii/binscii SHK images to avoid people
>getting corrupt files. This will mean another step in
>processing the archive but it beats down loading them
>from the net.

Good idea.  Some notes: if you chose GSCII encoding, the
file becomes transferable via text mode!  Yes, this solves
the browser problems once and for all.  GSCII converts the
files to 7-bit encoding, which is why this works.  Even if the
end-of-lines somehow get changed (as in, transfer via binary
instead of text), GSCII is smart enough to unpack them too.