Re: Kegs and HFS

[phoenyx <phoenyx@texas.net>]

Supertimer wrote:

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

I suggest Redhat 6.0. It comes in three sets. A basic version for
people who know what's going on (not me ;-) ) the standard set
which has an additional Cd with applications and 2 books. Then
there's the full set with even more programs on another CD. I
opted for the standard set.  Of course there's lots of new stuff
to learn but if you use GNO you got the basics down already.
My only problem now is I have so much fun playing with Linux
I don't always have time for my Apple projects.

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

GNU and Freeware software for Linux is constantly being updated.
There are lot's of good tools available for it now and more on the
way. Many people think the stuff needs to be Linux only but lots
of *nix programs can be compiled and run quite well. I like the
Netscape version better that the MS version. I can also use
the file browser with the KDE desktop. This is similiar to
using IE in windows.

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

Sorry for the confusion, I meant from the HFS to a Linux
filesystem. In the emulator there is no problems. I have occasionally
gotten a 'Generic FST' error while trying to copy too many
files at one time (in KEGS) but by selecting fewer file things
worked fine.

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

There is no way to avoid it when copying to Linux. By using
a GSCII wrapper though you eliminate the original file
losing it's attributes. Works well enough.

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

One the files are on the HFS volume and you've fixed
the file type problem or you put files on the volume from
a P8 disk the work fine. You only lose the info if you move
the file to any non-Apple fst such as ms-dos, win95,
Linux fs or fs2, etc...

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

I've only tried this with the HFS tools. But the support built into
the newer Linux is supposed to handle this also. There are two
ways to deal with HFS on Linux, via the kernel or the HFS utility
package.

Currently my system is configured with Mac/HFS partition
support compiled into the kernel, and the drive listed in the
/etc/fstab file. I let the kernel load the HFS module when
needed.  From X I run the Xhfs program which gives a nice
little GUI for transferring files.

Also the utils provided for HFS volumes recognize Apple II
file info. I thought this was kind of neat, but it probably is
beacause the Mac/HFS could support it.

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

I will probably still offer the .DSK and .dsk.gz for direct disk
transfer of floppies but I want to make it as easy as possible
for people using my programs.

One other note about Kegs/Linux Pc. Kent tries to set the
system up so you can easily write protect disks by setting
attributes. What you are supposed to end up with is an image
which works normally but doesn't actually get changed.

This doesn't work right with my system. A simple
hack to one file fixes this but the disk images are always
writeable unless you specifically tell Linux otherwise. This
doesn't bother me much since most of my work should be
stored permanently.

Phoenyx