Hi,
I’m currently trying to use the wip FTP API to send some binary data, were CR(0D) \r and LF (0A) \n can occur randomly in the stream. I noticed this bug when I was comparing the network-frame size I had before writing the data to FTP, and the resulting file on FTP server which had a different size.
In the following test I send the 2 sequences bellow :
ascii cars16[16] = {‘0’,‘1’,‘2’,‘3’,‘4’,‘5’,’\n’,’\r’,‘8’,‘9’, ‘A’, ‘B’,‘C’,‘D’,‘E’,‘F’};
ascii cars8[8] = {‘0’,’\r’,‘2’,‘3’,’\n’,‘5’,‘6’,‘7’};
An example of sequence 1, modem side, could be (I mixed ASCII code and hexadecimal value<> here for the sake of understanding) :
012345<0A><0D>89ABCDEF012345<0A><0D>89ABCDEF
Sequence 2: 0<0D>23<0A>5670<0D>23<0A>567
- In ‘I’ Image mode (default mode):
The result I get server side for sequence one is 012345<0D><0A><0D>89ABCDEF012345<0D><0A><0D>89ABCDEF
For sequence two I have 0<0D>23<0D><0A>5670<0D>23<0D><0A>567
One CR<0D> character is added before every LF<0A> character in the sequence.
- In ‘A’ Ascii mode :
The result I get server side for sequence one is 012345<0D><0A>89ABCDEF012345<0D><0A>89ABCDEF
For sequence two I have 0<0Dhas been removed>23<0D><0A>5670<0Dhas been removed>23<0D><0A>567
One CR<0D> character is added before every LF<0A> character if it is alone.
All the <0D> character that are alone are removed.
The <0A><0D> sub-sequences are replaced by <0D><0A> sequences.
I will had the test for ‘E’ mode later.
I’m not sure that the ASCII mode is supposed to do that but I’m sure the image mode is not supposed to modify the binary stream it is sending.
Is the fact that Image mode is modifying the stream a know bug ? Or is it an undocumented behaviour or (server-side) FTP setting misconfiguration ?
I know the workaround is to replace every <0D><0A> sub-sequence on the FTP file by <0A> but maybe there is a more elegant solution to this problem ?
I would also like to know if there are other undocumented transformation or known bug susceptible to modify add, remove other characters than CR or LF.
Best regards.