Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!rutgers!njin!princeton!phoenix!kadickey From: kadickey@phoenix.Princeton.EDU (Kent Andrew Dickey) Newsgroups: comp.sys.apple Subject: Re: NOTE: KERMIT-65 v3.85 & BINARY FILES Message-ID: <8092@phoenix.Princeton.EDU> Date: 2 May 89 23:49:04 GMT References: <46194@tut.cis.ohio-state.edu> Reply-To: kadickey@phoenix.Princeton.EDU (Kent Andrew Dickey) Distribution: usa Organization: Princeton University, NJ Lines: 52 In article <46194@tut.cis.ohio-state.edu> writes: >For anyone who's interested, I noticed a bug(?) in kermit, when trying >to upload a binary file from my Apple //e to Suns at school using >BSD4.2 UNIX. [Slightly edited...] Using Kermit's >binary file-type option, and without any terminal emulation or any >other problems of the sort, I consistently lost 12 bytes from this >file each time I tried to upload it. >By downloading it back (this time not losing any characters) and >writing a simple check program to find the differences, I found that >all the bytes missing had the value 13(decimal). By chance, Kermit's >End-Of-Packet (Kermit-65 is 'End-Of-Line') character is 13! >[Description of how he wanted to change the End-of-Packet character to >something else that was unused in his file.] >Interestingly enough, my little Apple //e and Kermit-65 let's you >change the End-Of-Line character to what ever you want, (both for send >and receive) but BSD4.2 doesn't! Forget Apple// vs. Mac-- let's take >on the Suns!!! The version available on my BSD Unix system DOES allow you to change the End-of-Packet Character--you should look into getting a newer version for your Sun. This is an interesting problem--I have been downloading many binary files from Unix lately (They are GIF's) and most have downloaded just fine. So, the bug may be in the Sun's Kermit...what version is it? In terms of my downloading, I have one file which just didn't send. It's about 29K long, and the transfer, just like all the others, goes just fine UNTIL THE VERY LAST BLOCK! At that point, I get 10 'Bad Checksum' errors in a row (as in, one program is calculating a bad checksum), and the transfer aborts. I am transferring over a 7-bit line, so 8-th bit prefixing is in effect. About 20 other files, some even longer, downloaded just fine. Anyone know anything about this? If you need more details (I'll work on making it bomb out on a smaller file, and then possibly send that to others to try out). I forget the version of Kermit on the Unix sys, but I am using 3.85 on my Apple. >[Long description of how he fixed it...] >I can probably put all these babies together so they work as one or >two automated file editors/stream editors for this problem, and post >it.... let me know if there is any interest... > >Jeff Stern >stern@cis.ohio-state.edu Even if no one else wants them, I can always use handy-dandy utilities like those to work on debugging odd transfer problems. Kent Dickey kadickey@phoenix.Princeton.Edu kadickey@PUCC