JRD@cc.usu.edu (Joe Doupnik) (12/15/89)
Hopefully the last of the Binary File Transfer comments for awhile. With Kermit, the file SENDER needs to be commanded SET FILE TYPE BINARY. This assumes the file sender stores files differently depending on whether they are text or binary or other format. If a binary file is sent from the PC to a mainframe host without this command then the host stores it in a default format (normally of little use or comprehensibility on that machine, but it's PC code anyway) or it coughs and sputters about buffer overflow. But watch out! The Kermit protocol says text files are sent with canonical end of line representation as CR/LF on the wire. Thus, a Unix host sending a file holding a \n (LF) as a text file will send CR/LF (\r\n) and that spoils real binary files. Word Processor files should be considered Binary because they usually have internal formatting information in non-printable characters; think of them as data files for a program called WordProcessor. Since everyone wants a simpler method of doing things, you can try an experiment with your local host. Send a PC .exe or .com file of some many KB in length, but send it first as a binary and then again as a text file. Get both back, using both methods. Now compare the four received versions with the original. Any differences indicates trouble and that method is doomed (rather like writing 360KB floppies in 1.2M drives, it works some of the time). The safe thing is to say SET FILE TYPE BINARY on the machine which distinguishes kinds of files, and do it regardless of the direction of file transfer. Automatic file type recognizers, the kind which read a small piece of the file beforehand, are few and far between and generally are not safe. Joe D.