I suppose it's possible that this is a binary file, and that it was originally transferred in ASCII mode, so that binary values that happen to match CR/LF got changed to be just CR. Then sending it to the 987 and back would be putting the CR characters back. It would be quite a coincidence, though, if the ONLY place that the LF characters appear in a non-text file is in a CR/LF combination. I'd expect both values to appear separately as well as (possibly) in combination in a binary file, in which case FTP wouldn't know where to put the CR characters when it added them back, and the file would still be corrupted. Wayne "Emerson, Tom # El Monte" <[log in to unmask]> on 11/06/2000 04:33:38 PM Please respond to "Emerson, Tom # El Monte" <[log in to unmask]> To: [log in to unmask] cc: (bcc: Wayne Brown/Corporate/Altec) Subject: Re: [HP3000-L] FTP to UNIX My response was similar, but the part that REALLY doesn't make sense is a difference of 67 bytes for a 125 THOUSAND byte file -- somehow I doubt the file is only 60+ records long... > -----Original Message----- > From: Wayne Brown [mailto:[log in to unmask]] > I'm just guessing, but I suspect that there are 67 lines in > your file and that a > carriage return is getting added to each line when it is > transferred back from > the 987. [...] > Steve Hammond <[log in to unmask]> on 11/06/2000 03:26:25 PM > [...] The original data file in the Sun system > has 125,807 bytes, when it comes back from the 987 it has 125,874. > > What are those extra 67 bytes and what difference did they make.