Re: Kegs and HFS

[supertimer@aol.com (Supertimer)]

dempson@actrix.gen.nz (David Empson) wrote:

>Supertimer <supertimer@aol.com> wrote:
>
>> phoenyx <phoenyx@texas.net> wrote:
>> 
>> >  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.
>
>No it doesn't.  The IIgs file type and auxiliary type are packed
>together and stored in the HFS file type field (part of the Finder
>Information record).  The HFS creator field is always set to 'pdos'.
>
>You might be thinking of the other way around: copying a Mac file to a
>ProDOS volume stores the Mac type/creator in the extended key block, not
>the directory entry.

Aha, now it makes sense.  I've always wondered, what would
happen to a Mac file that is copied by the IIGS Finder to a
ProDOS disk, then back to an HFS disk.  Can the IIGS HFS
FST do the same type of "ProDOS storage" of Mac file info that
the Mac itself does?

>> 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.
>
>If Mac file types are preserved when copying around from Linux, then
>ProDOS ones would be as well.
>
>More likely: Linux just copies the data fork, leaving the resource fork
>and Finder Information behind.  A default file type/creator would then
>be assigned when the file gets copied back to HFS.

That would be bad for both IIGS and Mac files.  I wonder why
Linux doesn't behave more correctly in regards to HFS.  If it
is implemented on Linux, then Linux should be made aware
of Finder Information and resource forks.  Probably a work in
progress, I guess.

>> >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!
>
>Do you perhaps mean BinSCII encoding?  GSCII is just one program which
>supports the BinSCII encoding method (along with several related ones).

Right.  Encoded by GSCII I meant.