Ascii mode problem from linux to windows

Question

I believe there is a problem in version 1.5.4 of the free edtftp java library. When you are trying to transfer an ascii file from linux to windows, and you set the transfer type to ascii, it does not properly convert the EOL character. In fact, it doesn't just not convert them - it strips all the LF characters!

Looking at the code...

                        // if previous is a CR, write it out if current is LF, otherwise
                        // write out the previous CR
                        if (crFound) {
                            if (lfFound) {
                               out.write(LINE_SEPARATOR, 0, LINE_SEPARATOR.length);
                               size += LINE_SEPARATOR.length;
                               monitorCount += LINE_SEPARATOR.length;
                            }
                            else {
                                // not CR LF so write out previous CR
                                out.write(CARRIAGE_RETURN); 
                                size++;
                                monitorCount++;
                            }                           
                        }
                        
                        // now check if current is CR
                        crFound = chunk[i] == CARRIAGE_RETURN;
                       
                        // if we didn't find a LF this time, write current byte out
                        // unless it is a CR - in that case save it
                        if (!lfFound && !crFound) {
                            out.write(chunk[i]);
                            size++;
                            monitorCount++;
                        }

you can see that this will work when going from windows to linux. However, when going from linux where the eol is just an LF, this code just eats them - it doesn't write anything out to the output stream. That is, if lfFound is true but crFound is false, then it doesn't do anything with that LF. What it SHOULD do is when it encounters a LF, it needs to see if the previous or next char is a CR. If it's not, and the LINE_SEPARATOR variable is CRLF, then it needs to write CRLF to the output stream.

I would write some of this code myself, but I'm in the middle of finishing up some code for a project which goes live this weekend. FORTUNATELY in my project ascii files are transferred to a linux box so I don't have to deal with this - I just happened to notice this in testing some code on my windows laptop.

As a workaround you can set the mode to binary, but that just leaves all the LFs in there - depending on what you are doing that may be ok on the destination windows box.

Hope this helps...

Answer 1

There is a flaw in your analysis. You've quoted code from the get() methods, and asked what happens if the line separator is just a LF.

However when you are getting data from the FTP server, the server itself converts the EOL to CRLF no matter what the platform EOL characters are.

So when you are getting files via FTP, the ASCII stream always has CRLF as the line separator. See RFC 959.

Answer 2

I looked at each byte coming down from the server... is this a problem on the server side then? There was definitely no CR in the ascii stream coming down from the server.

Answer 3

Yes, the server isn't conforming to the RFC. Interesting - perhaps we need to permit the user to set the ASCII EOL so that in these cases the translation can still be performed.

What is the server?

Answer 4

The server is vsFTPd version 2.0.1 running on RHEL 4. But we have a nearly identical server with the same version of vsFTPd and it works fine... I'm thinking a misconfiguration maybe? I emailed one of our admins to take a look at it.

Thanks.

Answer 5

Interesting... it was a server configuration. Looks like by default vsFTPd has ascii upload/download DISABLED by default. Got the admin to change it and it works just fine.
Thanks.