On Tue, Jul 19, 2011 at 9:54 PM, dlj <dave.jack...@gmail.com> wrote: > Unfortunately that didn't work. It looks like the problem may lay in > GenericFileProducer.createTempFileName(). The method attempts to normalizes > the filename, but the normalizePath( filename ) method on the > RemoteFileProducer doesn't do anything except return the path as-is. At this > point, the filename still contains a mixture of Unix and Windows file > separators. > > In the same method, the code which calculates the path to ultimately build > the temp file name on the ftp server, uses the '/' returned by the > RemoteFileProducer.getFileSeparator() to figure out the full of the path > using the filename which still contains a mixture of separators. The > calculation returns the result effectively ignoring the windows portion of > the path which I assume is not the desired behaviour. Later, the temp file > is ftp'ed, but when the rename occurs from the temp file to the actual > destination folder, then if the folder doesn't exist it fails. > > Could the RemoteFileProducer.normalizePath() method be changed to call the > normalizePath() on the ftp endpoint configuration. Not sure if this is a > sensible solution, if there's wider regression impacts to consider or > there's a better way?. Thanks. >
Thanks for the explanation. Can you create a JIRA ticket with this bug? I will look into this. > -- > View this message in context: > http://camel.465427.n5.nabble.com/FTP-temp-file-not-being-created-correctly-on-Windows-Camel-2-7-2-tp4591581p4613459.html > Sent from the Camel - Users mailing list archive at Nabble.com. > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/