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. -- 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.
