Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 UW 5/3/83; site uw-beaver
Path: utzoo!watmath!clyde!burl!ulysses!cbosgd!ucbvax!decvax!tektronix!uw-beaver!info-mac
From: info-mac@uw-beaver (info-mac)
Newsgroups: fa.info-mac
Subject: Re: Macput Questions
Message-ID: <1562@uw-beaver>
Date: Fri, 24-Aug-84 20:44:47 EDT
Article-I.D.: uw-beave.1562
Posted: Fri Aug 24 20:44:47 1984
Date-Received: Sun, 26-Aug-84 06:43:48 EDT
Sender: daemon@uw-beave
Organization: U of Washington Computer Science
Lines: 22

From: Carl D. Howe <cdh@BBNCCX.ARPA>
Funny, I was doing file transfers just last night and ran into the same
problem you experienced and with both versions of the program.
After a great deal of fussing about and trying to recreate situations that
DID work before, I discovered that the problem was related to
running over a TAC port or by being telneted to another host to do
the download.  My suspicion is not that the path isn't 8 bits wide, but
that nonprinting characters are being flushed or added.  TACs are known
to add padding NULs at the beginnings of lines unless you turn it off.
And you probably do need binary mode also.

I also worry about the TAC intercepting acknowledgment characters going the
other way, but given that most of them are unprintable (e.g. ACK, NAK, etc.)
I don't think this is the primary problem.

I cheated; I solved my problem by moving to a machine to which I was directly
connected.  Interestingly enough, both macput and the resource file seem to
happily reside on a machine with 10 bit bytes.  They even work.

Hope this helps,
Carl