Re: Sun to Mac to //c and back

[shack@onyx.southwind.net (Randy Shackelford)]

Nathan Mates (nathan@visi.com) wrote:
: In article <5081m7$kuh@europa.frii.com>,
: Randy Shackelford <shack@deimos.frii.com> wrote:
: >In article <507pv7$s38@darla.visi.com>, Nathan Mates <nathan@visi.com> wrote:
: >>   Shoulda noticed this before; the problem (as email conversations
: >>seems to have turned out) comes down to 3 letters: M-A-C. Idiot box
: >>****ing insisits on adding resource forks to files, making them
: >>unreadable under ProDOS 8.

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

:    There's a difference between copying off, which never started with
: a fork, and downloading, which the downloader _does_ add the fork,
: as many have demonstrated in the past few weeks here, as well as over
: email. (As maintainer of the FAQ, I get people emailing me for help.
: For every one on the newsgroup, there are 3-4 with the problem)

Verifying that the file copies without having a resource fork added is part
of the problem solving process. The ProDOS file system extension, the 
predecessor to PC exchange's ProDOS support, ALWAYS wrote files as extended
type $00 files. So ensuring the file doesn't become extended during copying 
reduces the problem to making sure the file isn't forked before copying, right?

FWIW, I transferred the binscii file for that lambda demo thing which I saved
from comp.binaries on this host to my mac using Fetch set for binary transfer.
When I checked it to see if it had a resource fork after downloading, it had
none.

: >>   I am > < (fingers about 1/8" apart) close to actually recommending
: >>that people wishing to download stuff to Apple IIs AVOID Macintoshes
: >>completely. In the FAQ. This is because of their BONEHEADED and
: >>UNNECESSARY inisistence on adding resource forks.

: >Doing so would be propagating an inaccuracy, something you've been railing
: >against so much lately.

:    Fact: downloading to a mac, then copying to a ProDOS disk has
: caused one hell of a lot of problems. Are you denying all those who
: _have_ had all these problems with resource forks, and claiming that
: those never happened? If someone can isolate things to a given mac ftp
: program and os version, then I'll clarify that in the FAQ. In the
: meantime, I have seen no common thread of precisely what program(s)
: and/or converter(s) on the Mac is at fault.

: > I have my workstation equipped //e and my IIgses
: >networked with my Macs, and I can transfer files under ProDOS 8 and they
: >work slicker than snot.

:    I'm talking downloading, not copy off. 

Your statement is "don't use a Mac at all to download files because you can't
access them with ProDOS 8" or "downloading to a mac, then copying to a ProDOS
disk has caused one hell of a lot of problems". I download every file I get
using fetch. Then I use localtalk to get files to my IIs. Your statement would
lead people to believe that this method won't work, when it does. You can 
access even forked files on server volumes with ProDOS 8, with nary a hiccup.
I can access my 2 gig hard disk and 230 mb magneto optical disks with ProDOS 8
for that matter, when I'm logged on to Appleshare and they are server volumes.

: >>   When something appears to do what you want, but prevents you from
: >>actually doing it, that is worse than not supporting it directly.  If
: >>it's going to trip up far more people than will benefit, I'm going to
: >>recommend against such things.

: >What say you get off your Mac hating high horse and help find a solution?

:    I have no mac, and no easy access to one. I've tried asking some of
: those with the problems, and there is nothing in common that I can
: determine. When I see a chronic problem that has no easy solution, and
: any possible solution is _way_ out of the ability of Joe clueless user
: to deal with, I will take the road that it is better to avoid the
: problem.

There's the problem. If you don't have a Mac, why not ask someone who does
if they can help? Why ask the people who don't know what they're doing?
As you'll see in another article, I found a way to get rid of resource forks
with a five minute trip to info-mac. And as you will see in this article, I
even got fetch to download a file without adding a resource fork to it.

:    Macs have their uses, and I'll support them on their
: strengths. From what I've seen, this is NOT a strength, but a serious
: detriment. Mac geeks may say "oh, just do this with ResEdit, and
: everything will be fine." If such things _are_ necessary, why is
: ResEdit (or easy filetype changing capability) _NOT_ part of the
: system software? Why doesn't it work right from the start? Why does
: the mac purport to be user friendly, yet require serious hackery to do
: something the OS "supports?

Who uses resedit? There's a handy extension called get more info which
can change file types and creators and shows the sizes of the file's forks
to boot.

The Mac system, and IIgs system for that matter, are easily extensible. That
allows people to add functionality they want and leave out stuff they don't.
As it should be since having everything everyone would want would make a bug
riddled Swiss Army knife operating system. I doubt many Mac-noids have much
reason to need to change file types arbitrarily, but it's simple to add the
capability. I also doubt many Mac users use ProDOS disks so I'd be happy that
you can access ProDOS disks at all. I figure the support is mostly intended
for transfers the other way. You've seen the rumor that Copland won't ship
with ProDOS support right?

:    Please note that I'm bashing macs on _this_ issue. End of story.

: >Failing that, I have a ProDOS 8 program I wrote for my own use which can read
: >an extended file's data fork and write its data into a standard file. I also
: >have an unfinished program for deleting extended files under ProDOS 8. Last
: >I worked on it, it worked except for causing the blocks_used field of the
: >volume directory header on the affected disk to be off by one.

:    Clue: this is for the c.s.a2 FAQ, especially in the downloading
: Binscii and Shrinkit section. An arbitrary program to FIX the problem
: with Binscii having a resource fork can NOT be downloaded. (Giving a 8
: line Applesoft file to fix the wrong CRLF mode is about the limit of
: what users can do). If you have a _short_ program (10 ML lines tops),
: that might doable for adding to the FAQ. Telling people that they have
: to type in a 20-40 line program to fix what the Mac ****ed up, you
: might as well tell them to avoid the heartache and ditch the mac from
: the _DOWNLOADING_ to the Apple II part of the equation.

I was just mentioning another option, one that is neither the simplest nor
the best. Part of problem solving is listing all the possible solutions
and picking the best one to use. This is one of the things drilled into your
head in officer training so it's second nature for me.

Just to make sure I wasn't seeing things, I ran Fetch and went to 
apple2.caltech.edu and downloaded a random file, Coolwriter 3.0 by name.
I put Fetch in binary mode (an obvious step to me, since Fetch's automatic
mode ain't gonna know any Apple II format) and when I was done, I checked
the file with get more info. It said RESOURCE FORK 0 BYTES. So I copied the
file onto my ProDOS 3.5 disk and ran Shrinkit. It opened the file with no
problem. So it isn't even necessary to use the drag and drop resource fork
stripper app I got from info-mac if you do the download right. There's no
need to even worry about changing the file type with shrinkit files.

I've shown that copying the file to a ProDOS disk doesn't cause it to be
extended. I've even shown a way to keep fetch from adding a resource fork. 
We're about fresh out of ways to blame the Mac for causing downloads not to 
work.

:    Binscii and the first copy of Shrinkit is designed to be downloaded
: and run in absolutely MINIMAL setups. No other programs, no nothing.
: Macs' resource forks violate that at the moment. 

I went from scratch using IIe on my powerbook to get binscii and shrinkit
running off a ProDOS 3.5 disk, using fetch. It can be done and it ain't tough.
--
Randy Shackelford                                 US Air Force officer
shack@southwind.net                               and Apple aficionado