Re: Sun to Mac to //c and back

[nathan@visi.com (Nathan Mates)]

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:
>>In article <507993$2qv@Germany.EU.net>,
>>Joerg Heitkoetter <jh@Germany.EU.net> wrote:
>>>Then I start Fetch on my Mac and transfer the files to a ProDOS 720K
>>>disk; 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);

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

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

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

   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?

   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.

   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. 

Nathan Mates

--
<*> Nathan Mates http://www.visi.com/~nathan/      <*>
# What are the facts? Again and again and again-- what are the _facts_?
# Shun wishful thinking, avoid opinion, care not what the neighbors
# think-- what are the facts, and to how many decimal places?  -R.A. Heinlein