[ 
https://issues.apache.org/activemq/browse/CAMEL-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63101#action_63101
 ] 

Bengt Rodehav commented on CAMEL-3309:
--------------------------------------

I have now done a couple of recursive tests on Serv-U 10.2.0.2 and Filezilla 
Server 0.9.33 beta. Serv-U can be downloaded and evaluated for a month, 
Filezilla is freeware.

I think I was wrong when I said that the very existence of a subdirectory 
causes problems. It seems that "recursive=true" is required. I've done the 
following test on Serv-U - both without locking the user to the home directory 
and when I lock the user to the home directory. The latter will report the home 
directory as "/" and thus avoids the original "stepwise" problem. I've also 
done the test on Filezilla server to verify that it's not a Serv-U problem.

I have reverted to camel-ftp from the released Camel 2.5 version to exclude 
myself (and my patch) from disturbing the test. My test environment is a bit 
complex since I create the route with a lot of other options automatically 
(like for archiving, exception handling and such). The route I describe here is 
therefore not identical to what I've tested but I think it's close enough for 
you to reproduce the error.

My basic route is as follows:

from("ftp://u...@localhost/sample/file2ftp?password=password&recursive=true";).
to("file:C:/temp/sample/file2ftp");

If I drop a folder called "connect" with a subfolder called "samples" into 
<HOME>/sample/file2ftp then the folder hierarch being created in my local file 
system becomes:

C:/temp/sample/file2ftp/connect/connect
                                                 /samples/connect/samples 

Thus I get an extra "connect/samples" under the "connect/samples" directory.

I think this has to do with me not polling the ftp home directory but a 
directory two levels down in the home directory. If I change the route to

from("ftp://u...@localhost/?password=password&recursive=true";).
to("file:C:/temp/sample/file2ftp");

and drop the "connect" folder (with subfolder "samples") direct into <HOME> 
then it works correctly.

Thus, I think the problem with recursive is a bug in Camel 2.5 that is 
unrelated to the "stepwise" problem that this issue is about.

I'm interested to see whether you get the same results as me. If so, then one 
of us should create a new JIRA ticket for the recursive problem. As far as I 
can tell my patch works for the "stepwise" issue but I hope you will examine it 
as well.

> Stepwise change of directory unfit for production (ftp/ftps/sftp)
> -----------------------------------------------------------------
>
>                 Key: CAMEL-3309
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-3309
>             Project: Apache Camel
>          Issue Type: Improvement
>          Components: camel-ftp
>    Affects Versions: 2.5.0
>            Reporter: Bengt Rodehav
>         Attachments: camel-ftp.patch
>
>
> In Camel 2.5, the logic for changing directory for ftp/ftps/sftp has changed 
> in order to fix the problems discussed in the following thread:
>   
> http://camel.465427.n5.nabble.com/How-to-change-directory-while-using-sftp-component-td2806817.html#a2807611
> In Camel 2.5 changing of the remote directory is now done in a stepwise 
> manner. This is a strategy not fit for production since it assumes that the 
> logged in ftp/ftps/sftp user has access to all intermediate directories all 
> the way down to its home directory. This is rarely the case.
> Also, when testing ftp/sftp on Serv-U, a Windows based ftp/ftps/sftp server, 
> it turns out that it reports the current directory in a "Windows way", e g 
> /C:/temp/servu/user/sample/file2sftp. The topmost folder is not "/" but 
> "/C:". This also breaks the new stepwise way of changing directory since it 
> always tries to change to "/" if an absolute path is used.
> I propose to introduce a configuration property to enable/disable stepwise 
> changing of directories where disabling it should be the default. I will 
> upload a patch shortly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to