Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Message-ID: <4580290.11081289078760386.JavaMail.jira@thor>
Date: Sat, 6 Nov 2010 17:26:00 -0400 (EDT)
From: "Bengt Rodehav (JIRA)" <jira@apache.org>
To: camel-dev@activemq.apache.org
Subject: [jira] Commented: (CAMEL-3309) Stepwise change of directory unfit
 for production (ftp/ftps/sftp)
In-Reply-To: <25114838.6221288858079968.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


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

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

Like I wrote earlier, the URI I use is a bit more complicated than I wrote here since my software has logic for changing the URI in different ways. I've picked my URI apart bit by bit to see if I can get the recursive method to work (like it works for you Claus). I turns out that I always add the following option to the "toUri":

  ?tempFileName=${file:name.noext}.tmp

This is to make sure that any software reading the file that is being transferred don't start reading the file before it is completely transferred. Although it might not make sense to have this on the to("file:..."), it does so in our case. This is because we download files into a DMZ. We then have another instance of our software (using Camel) that moves the files from the DMZ into the secure zone. We don't want that other instance to start reading the files to early. Now that I think of it, the other instance of our software actually acts as a client to Serv-U contrary to what I wrote before.

It seems like this option is causing the problems. Claus, can you add the above option to your "toUri" to see if you get the same problem?

> 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
>            Assignee: Claus Ibsen
>         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.