FTP Move fails - have found cause but don't understands why

[rbogdanoff <ro...@gmail.com>]

Hi,

I am used camel 2.12.3

I am using an FTP consumer.

ftp.mysite.com/mydir/mydir2?username=abc&password=abc&streamDownload=true&move=.done&delay=600000

There is a file in /mydir/mydir2 named xxx.xxx but the move fails.  I
debugged the code and found the cause.

In org.apache.camel.component.file.remote at line 255 the rename is executed

    public boolean renameFile(String from, String to) throws
GenericFileOperationFailedException {
        log.debug("Renaming file: {} to: {}", from, to);
        try {
            *return client.rename(from, to);*
        } catch (IOException e) {
            throw new
GenericFileOperationFailedException(client.getReplyCode(),
client.getReplyString(), e.getMessage(), e);
        }
    }

the from is /mydir/mydir2/xxx.xxx and the to is /mydir/mydir2/.done/xxx.xxx

the 'client' in line 255 is org.apache.commons.net.ftp.FTPClient.rename(...)

org.apache.commons.net is version 3.3 (as per the camel pom)

That code org.apache.commons.net.ftp.FTPClient.rename line 2557 looks like
this

    public boolean rename(String from, String to) throws IOException
    {
        *if (!FTPReply.isPositiveIntermediate(rnfr(from))) {
            return false;*
        }

        return FTPReply.isPositiveCompletion(rnto(to));
    }

So, FTPClient does the rename in two steps - rnfr and rnto.

when rnfr executes it send "RNFR /mydir/mydir2/xxx.xxx" to the ftp server.

The ftp server response back with the reply "250 Directory successfully
changed."

so rnft(from), which return an int, with return 250.   

However the code in isPositiveIntermediate looks like this...

    public static boolean isPositiveIntermediate(int reply)
    {
        return (reply >= 300 && reply < 400);
    }

so, the return code from "250 Directory successfully changed." will return
false as it is not between 300 and 399 and the seconds step for the rename
rnto(to) never executes and *false*is returned to camel which then thrown a
GenericFileOperationFailedException 

It seems to me that the reply from the ftp server of "250 Directory
successfully changed." should be OK for the RNFR step of
org.apache.commons.net.ftp.FTPClient.rename.  

I have to believe others have run into this?

Any advise?

Regards
Ron Bogdanoff






--
View this message in context: http://camel.465427.n5.nabble.com/FTP-Move-fails-have-found-cause-but-don-t-understands-why-tp5748358.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: FOUND CAUSE! - FTP Move fails - have found cause but don't understands why

[rwijngaa <ri...@gmail.com>]

I've experiencedalmost the same problem with this streamDownload option (i
got a lot of exceptions on renaming the file to Archive).
Now i'm using the localWorkDirectory option instead and this seems to work
better!

Regards
Rino



--
View this message in context: http://camel.465427.n5.nabble.com/FTP-Move-fails-have-found-cause-but-don-t-understands-why-tp5748358p5767329.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: FOUND CAUSE! - FTP Move fails - have found cause but don't understands why

[rbogdanoff <ro...@gmail.com>]

I did more debugging and found the cause

If you have streamDownload=true 

Take a look at 
org.apache.camel.component.file.remote.FtpOperations.retrieveFileToStreamInBody(....)

at line 345

            if (endpoint.getConfiguration().isStreamDownload()) {
                InputStream is = client.retrieveFileStream(remoteName); 
                target.setBody(is);
               
exchange.getIn().setHeader(RemoteFileComponent.REMOTE_FILE_INPUT_STREAM,
is);
                result = true;
            } else {
                os = new ByteArrayOutputStream();
                target.setBody(os);
                result = client.retrieveFile(remoteName, os);
            }

If you have streamDownload=true (the default is false) the FTPClient gets
into a different state than what FTPOperations expects.  Then from that
point on, every time there is a call to FTPClient, the FTPClient is "one
call behind" what FTPOperations thinks it is and you get strange behavior.

I am hoping that this is enough info for the people that are knowledgeable
of this code to see the issue.  



--
View this message in context: http://camel.465427.n5.nabble.com/FTP-Move-fails-have-found-cause-but-don-t-understands-why-tp5748358p5748371.html
Sent from the Camel - Users mailing list archive at Nabble.com.