dk1z+@ANDREW.CMU.EDU.UUCP (06/03/87)
An employee here at CMU is generating compressed MacPaint documents on a UNIX system and downloading them to a Mac for display. Downloading a compressed file works correctly. MacPaint displays the file properly and there are no errors in it. The file was then uploaded to the UNIX machine. At some stage of the upload, all 0d's were changed into 0a's. This happened in every occurance. We tested this with Stanford's and NCSA's FTP and tried going to three different UNIX machines. In all cases, the 0d's went to 0a's on the upload. I am at a loss to determine just where this bit flip is occuring. Could it be in the Kinetics gateway, running the latest KIP? *Any* ideas at all would be appreciated, as would any other suggestions for tests that we might run. -David C. Kovar
maas@AHWAHNEE.STANFORD.EDU.UUCP (06/03/87)
Dave, You might want to transfer it in image mode. In ascii mode, Stanford FTP does the Newline conversion. From a mac to a remote host, it will replace CR(Macintosh Newline char) into CRLF sequence (Telnet newline sequence). The reason you only see a LF instead of CRLF is because the FTP server in UNIX side convert CRLF into LF (UNIX Newline char) Andy