We can send and receive files to our OFTP2 partner using mendelson OFTP2 software.
But when we send a file to our partner it will somewhere along the road get illegal control characters at the end of each line in the file.
The illegal characters is \r\n
The characters is not in the original file.
When receiving files from the same partner there is no illegal control characters at the end of the line(s)
Has anyone heard of this and is it a setting in the OFTP2 software that need to be set or is there another solution to this issue?
Info about software installed:
Mendelson opensource OFTP2 1.0 build 19
Installed on windows server 2003 R2 with SP2
Bo,
the mendelson OFTP2 software reads the data as binary stream - it does not translate any CHR LF characters. Any encryption/signature of the data would elsewere not work.
But perhaps you could give us some more details, what OS are you and your partner using? Have you tried to encrypt the data, does it work? If you zip the data, is it broken on the partners side etc?
Is it possible that the problem has nothing to do with the transmission software, e.g. by a send process via FTP to the OFTP poll directories or something like that?
Regards
Hi Thank you for your reply.
I'm trying to send data to Volvo. They do not support encryption when sending, but rely only on SSL.
We use windows server 2003 R2 SP2 for the OFTP2 server. I'm awaiting info from Volvo about the OS setup in their end.
Im trying to send a file manually using "send file" so it should not have anything to do with FTP og OFTP poll directories
Does anyone have a solution for this issue. I cannot get any help from Volvo about this. I can send the files in a zip file and then the files inside look ok. But this is not a solution as this requires manual work when sending files.
I'm pulling my hair out because of this. Please help me
I can't really help... sending the file manually seems to be the only option that would work.
____________
pdf converter
If you are using Windows, the file is most likely in the "DOS Format", which means that every line terminates with CR-LF (or "\r\n"). You can verify that by opening the file in a hex editor and looking for "0D 0A" at the end of each line.
You probably need to translate the file to "Unix Format", which removes the CR (or "\r" or hex 0D) so that the lines end with just the LF ("\n" or hex 0A).
A small command-mode utility called "flip" can be useful:
https://ccrma.stanford.edu/~craig/utility/flip/flip.exe