Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pacbell!att-ih!ihnp4!inuxc!iuvax!pur-ee!uiucdcs!uxc.cso.uiuc.edu!clio!peltz
From: peltz@clio.las.uiuc.edu
Newsgroups: comp.sys.mac
Subject: SFGetFile bug in Kermit?
Message-ID: <17000095@clio>
Date: 12 Mar 88 02:57:00 GMT
Lines: 32
Nf-ID: #N:clio:17000095:000:1680
Nf-From: clio.las.uiuc.edu!peltz    Mar 11 20:57:00 1988


I just ran across a very strange bug in Mac Kermit version 0.8(33) that
has me very puzzled. I'm wondering if there is a later version which
fixes it.

Symptom is that I when I go to Send File, I either get only files which have
resource forks AND are not type APPL, or I get all files which have resource
forks in them. Then, even if I select a file with a data and resource fork,
and have data fork selected, it sends the resource fork.

I'm not sure what occurs when it starts allowing APPL files, but once it does,
it continues allowing them.

Inserting a diskette into the finder, then ejecting it cures the problem until
I reboot (I normally run off a hard disk only).

I am using a Mac II, with the instruction cache turned off so that Kermit
doesn't bomb (is there a version which cures this, also?). It doesn't appear
to be associated with whether I run under Multifinder or not. System 4.2,
Finder 6.0. I can't test this on a Mac+ since I don't have one which has a
hard drive.

I keep hearing about how the newest version of Kermit doesn't handle parity
correctly. Is there a fixed version yet? It would be nice, as someone else
previously mentioned, if it would also allow for specifying data bits and
parity separately. I know the 8530 SCC can handle it.

BTW, the person who complained that the "serial chip" in the Mac was dumb
because it couldn't be programmed to pass on characters with bad parity: the
SCC certainly can; all it does is set a status bit. It is the serial driver
which throws the character away if that bit is set. I'd like to be able to
specify to the driver that I DO want parity generated on output, but that I
want to ignore parity coming in.