camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bengt Rodehav <>
Subject Sftp bug in Camel 2.11.0
Date Fri, 03 May 2013 14:35:40 GMT
Unfortunately I seem to have found another bug in Camel 2.11.0 regarding
sftp. I noticed it when I removed the "stepwise=false" argument from my
routes thus enabling the default stepwise way of changing directory.

The problematic section begins at line 404 in

*404:*        if (getCurrentDirectory().startsWith(path)) {
*405:*            // use relative path
*406:*            String p = getCurrentDirectory().substring(path.length());
*407:*            if (p.length() == 0) {
*408:*                return;
*409:*            }
*410:*            // the first character must be '/' and hence removed
*411:*            path =
*412:*        }

The problem does not arise when stepping down into the directory to poll
but when going back to the directory where we started. Assume that the home
directory in the sftp server is "/" and I want to poll the directory "in"
relative to the root. My endpoint would look something like this:


What happens is that the "i" in "in" is removed and Camel attempts to
change to directory "n". Looking at the code above, the following happens:

- The current directory is "/in" since we have previously succeeded in
moving there and polling for files. We are now attempting to go back to
where we started, therefore "path" is "/".
- On line 406, the variable "p" will be set to "in", thus removing the
leading "/".
- On line 411 an incorrect assumption is made: It is assumed that the first
character must be "/" but the leading "/" was removed on line 406. The
result is therefore that "path" is set to "n" instead of "in".

I haven't investigated when this error was introduced. I did however
compare with the corresponding logic in In that file
the section quoted above does not exist at all. It seems to me that the
purpose with this code is to, stepwise, change directory up to ".." - one
directory at a time instead of going straight to "/". It seems very
unnecessary to me but I assume there is a reason for it. Otherwise, the
easiest change would be to just remove the code above and use the same
logic as in

Currently my only workaround is to use "stepwise=false".


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message