Re: FYI> Hitch-Hiking from Sun/*NIX to Apple // via Mac and back

[dempson@actrix.gen.nz (David Empson)]

Joerg Heitkoetter <jh@Germany.EU.net> wrote:

[snippage]

> I compile nulib and find that my CHAMELON.SHK file contains the
> things I want:
> 
> jazz(jh): ~/tmp/apple2> nulib v CHAMELEON.SHK
>  CHAMELEON.SHK   Created:01-Jul-91  21:52   Mod:01-Jul-91  21:52
>                  Recs:    2
> 
>  Name             Kind  Typ  Auxtyp Archived         Fmat Size Un-Length
> ------------------------------------------------------------------------
>  CHAM.SYSTEM      File  SYS  $2000  01-Jul-91  21:52  shk  83%     19516
>  CHAMELEON.DOC    File  TXT  $0000  01-Jul-91  21:52  shk  54%     27341
> 
> (have an eye on the "Typ" section) so I extract the files:
> 
> jazz(jh): ~/tmp/apple2> nulib xv CHAMELEON.SHK
> Extracting 'CHAM.SYSTEM' (data)...overwriting...unshrinking (I)...done.
> Extracting 'CHAMELEON.DOC' (data)...overwriting...unshrinking (I)...done.
> 
> Then I start Fetch on my Mac and transfer the files to a ProDOS 720K
> disk;

It would be an 800K disk.  The Apple II doesn't support 720K disks
unless you have a SuperDrive and a SuperDriver controller, or something
similar.

> great I think and move the disk over to the //c and voila
> the disk is readable; but--the files have type $00 not SYS and TXT
> as expected; ok I thought, let's bload the files and bsave them with the
> appropriate type; but this doesn't seem to work; it's
> always WRONG FILE TYPE (load, bload, run, exec, whatever);

Each command in ProDOS basic expects a certain file type.  LOAD/RUN are
only for BAS (Applesoft BASIC), EXEC is only for TXT files that contain
BASIC commands (or ProDOS commands).  The only "universal" command is
"-", which starts a program using the appropriate method (EXEC for a
text file, RUN for BASIC, BRUN for binary, or launching a SYS file
directly).

BLOAD and BSAVE assume a BIN file by default, and report a FILE TYPE
MISMATCH if you attempt to use them with another file type.  You can
override this with the "T" argument (specifying the file type), but you
also have to specify a load address.  In this case, the correct command
would have been:

BLOAD CHAM.SYSTEM,T$00,A$2000

You could then save it back as a SYS file as follows:

DELETE CHAM.SYSTEM
CREATE CHAM.SYSTEM,TSYS
BSAVE CHAM.SYSTEM,TSYS,A$2000,L19516

(The length is obtained from the "Un-Length" column in the NuLib listing
earlier; it should have also been reported by an 80-column CATALOG
command.)

> So here's the question: How do I change the attribute of a ProDOS
> file from $00 to SYS/TXT/whatever? and What's wrong in the above?

I'd normally use a file type changer utility, but the above method will
work for most files, as long as they aren't too big.


In a subsequent quoting, shack@deimos.frii.com (Randy Shackelford)
wrote:

> If a file has no resource fork, copying it to a ProDOS disk doesn't add
> one; I just verified this on my Powerbook. I took a copy of Appleworks on
> a 3.5 disk and copied all the files to my Powerbook's RAM disk, then put
> in a blank ProDOS disk and copied 'em to it. Appleworks ran fine off this
> disk.

This is true, but it only works because the files have a creator of
'pdos' and a known file type.  If you take an arbitrary Mac file (with
any creator other than 'pdos', or an unrecognised file type) and copy it
to a ProDOS disk, the Mac will make it into an extended file, so that it
can preserve the Mac file type and creator.

Any such file cannot be accessed by ProDOS-8, unless you run a resource
fork stripping utility on it.

To ensure a file will end up as a standard file on a ProDOS disk, make
sure its file type is set to 'TEXT' and its creator to 'pdos', BEFORE
copying it to the ProDOS disk.

You can then use a file type changer on the Apple II to set the correct
file type.  If it is supposed to be a SYS file, you can set the Mac file
type to 'PSYS' before copying the file.  Most other file types require a
binary encoded file type which cannot be entered from the keyboard.


Back to Joerg Heitkoetter <jh@Germany.EU.net>:

> Good point, resource forks are no problem if all downloads have been
> done in binary mode;

Not necessarily.  If the file ends up with the wrong file type/creator,
then it will be unusable by ProDOS-8 (see above).

> What does ProDOS stand for? Professional or Problematic DOS?

Professional, but only if you have good utilities.  The actual operating
system doesn't have a user interface - most of your hassles have been
with BASIC.SYSTEM, which is rather primitive.

ProDOS itself doesn't care about file types (except for SYS and DIR).

>      BLOAD FUBAR,T$00,A$1000,Lxxx
>      CREATE BARFU,TSYS
>      BSAVE BARFU,TSYS,A$1000,Lxxx
> 
>      Where 'xxx' is the file length of the file. If you didn't force
>   binary mode in downloading, the filesize will pribably be different
>   from what nulib showed.
>
> Now, here comes the fun part: my ProDOS downs't have this byte count
> (which anyone else seem to have) I would need for the ",L<bytes>" option.
> A "CAT" on my system just gives me FILENAME, TYPE, LENGTH IN BLOCKS and
> MODIFIED DATE; I seem to have a very old version of ProDOS? (It's ProDOS 8
> v1.9 10-Jul-89)

CAT is the 40-column version of the catalog.  You need to use CATALOG to
get all the fields, and you must be in 80-column mode to read it.

> And when I try the above I ALWAYS get a "FILE TYPE MISMATCH" error, #@$@$@!

This may be because the files are extended (see above) and therefore
unreadable by ProDOS.

BASIC.SYSTEM has a small set of error messages, and it uses the same
message for several ProDOS errors.  In this case, it is probably getting
a ProDOS "unsupported storage type" error, and displaying the message
which is the closest match.  A large number of errors collapse into a
generic "I/O ERROR", which doesn't tell you very much.


Summary time:

> Well--I still don't know why my ProDOS' CAT doesn't list the byte count of
> a file.

Because it doesn't fit.  Use CATALOG.

> Resource forks are no problem, if all downloads happen in binary mode;
> forks are added on ProDOS disks, but they are separated from the files,
> just like on PC disks; i.e., they do NOT modify the file content.

Wrong on most counts.

1. The binary download is necessary to ensure that CR and/or LF are not
changed.

2. To ensure the file has no resource fork (strictly speaking: to ensure
the file is standard, not extended), it is necessary to set the creator
to 'pdos' and the file type to 'TEXT', 'PSYS' or an appropriate ProDOS
file type (which cannot be entered on the keyboard, since it requires
entering three binary values from 0-255 as a character) before copying
the file to the ProDOS disk.

3. On a ProDOS disk, an extended file (with data fork and potentially a
resource fork) is stored as two logical files, with an "extended key
block" connecting the two forks.  The single directory entry points to
the extended key block, and a different "storage type" is used.  The
storage type indicates how the file contents are organised.  The major
storage types are: directory, one block files (seedling), multi-block
files with a single index block (sapling), multi-block files with a
two-level index (tree), extended files (which includes two forks, each
of which may be seedling, sapling or tree), and special files such as
PASCAL areas.  ProDOS-8 does not support extended files, but GS/OS (on
the IIgs) does.

By comparison, on an MS-DOS disk, the resource fork is stored as a
completely separate file in the hidden RESOURCE.FRK directory.  Any
Macintosh directory information is stored in a hidden file somewhere
else.  The PC is able to deal with the data fork quite happily, but it
is easy to get it separated from the resource fork, and to lose the
associated Macintosh directory information.

> Some problems may arise, when you download the files directly to the
> ProDOS disk; you have to store the files on the Mac's desktop; THEN
> copy the files to the disk; I still don't know why.

This may be something that Finder is doing to make things easier.  I
suspect that other programs writing directly to a ProDOS disk might
always create an extended file, but Finder only does this if necessary
(if the file already has a resource fork, or it has a non-ProDOS
type/creator).

> I guess that the file type can easily be changed with a sector/disk
> editor, since it's stored in the ProDOS directory entry somewhere;
> who knows which byte has to be changed?

You can change the file type this way, but it is easier to use something
like File Attribute Zapper.

However, changing the storage type using this method is NOT a good idea,
because the storage type reflects the physical structure of the file.
To change an extended file into a standard file, you would have to
manually extract the required information from the extended key block,
store it in the directory entry, then mark the extended key block and
the resource fork as free in the bitmap.  There is at least one utility
program to do all this.

-- 
David Empson
dempson@actrix.gen.nz
Snail Mail: P.O. Box 27-103, Wellington, New Zealand