[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Netatalk Apple II Share Corruption Q



Wendell III <wendell.iii@gmail.com> wrote:

> http://www.vectronicsappleworld.com/appleii/appleiiecard.html
> 
> In reading the above, I see:
> 
> "It is easy to corrupt Apple II programs with a MacOS resource fork.
> 
> Without the fork, Apple II files tend to tear up your MacOS hard drive
> or otherwise cause Norton Utilities and Apple Disk First Aid to 
> register all kinds of funny errors that they want you to fix. Don't 
> allow any MacOS utilities to work on any Apple II programs. This will
> destroy them.

That claim seems rather extreme.

There might be a problem like this if you store some IIgs applications
or documents on a Mac, if the IIgs document uses a resource fork.

8-bit Apple II software and documents will end up on a Mac volume as a
file which the Mac sees as a relatively small document with a strange
file type and a creator of "pdos", containing a data fork only.

Mac repair utilities won't even blink at this - they will leave them
alone.

If you do anything on the Mac which attempts to do something like add a
custom icon to any Apple II file, it will add a Mac resource fork to the
file. If the file is accessed from an Apple II over a network in 8-bit
software, this will be ignored. Some utilities on the IIgs (e.g. Finder
when copying a file) might notice the resource fork and try to do
something with it, but won't be able to interpret its contents if they
try to treat it as a IIgs resource fork (which has a different internal
structure). The Mac resource fork might get damaged if the IIgs software
tries to do something like add a resource.

A IIgs application or document using a IIgs resource fork is more likely
to trigger problems with utility software on a Mac: if the Mac software
tries to read inside the resource fork or modify it, it may complain
about a corrupted resource fork or actually destroy it in the process of
trying to modify the resource fork (e.g. adding a custom icon).

If you actually copied a file with a resource fork (either Mac or IIgs
format) to a ProDOS disk, it will end up being an "extended" file and
won't be accessible by 8-bit software. (See below for a related issue.)

> You should run these utilities after you do any conversion as explained in
> "How to get software off the Internet to run in a real Apple II". You may
> find that Norton has some work to do. Don't worry too much about anything
> held in OS X. OS X is much more robust. The safest way to store Apple II
> programs in any MacOS environment is in disk image format."

They are alluding to a problem which is caused by downloading Apple II
files on a Mac, then copying them to a ProDOS volume.

If the file doesn't have a properly formed creator ("pdos") and filetype
(an encoded Apple II file type and auxiliary type) then copying it to a
ProDOS volume will require storing it as an extended file, which is the
same underlying structure that the IIgs uses when a file has a resource
fork. ProDOS-8 is not able to access a file at all if it is extended,
because it doesn't know how to deal with that storage type. A IIgs will
be fine (in GS/OS, System 5 or later for safety).

> This seems to imply that my Netatalk shares are not the best place to
> store Apple II executables? Can anyone comment?

Don't worry about it. A linux box isn't going to try to mangle the
resource fork (it will presumably just store it as a separate file, or
use AppleSingle format) and for files created on the server from an
Apple II or Mac, it should preserve the Apple II file type information
somehow, in the same way as it would for a Mac client.

Manually copying files to a linux box (e.g. off the Internet) then
serving them via Netatalk might be problematic, because the Apple II (or
Mac) might not be able to access the resource fork or have the correct
metadata.
-- 
David Empson
dempson@actrix.gen.nz