[jira] [Updated] (CAMEL-14915) Why we're trying to create directory (FtpOperations.buildDirectory) when we have an FTPS route with no starting directory in camel ftps URI

["Jin Feng (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-14915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jin Feng updated CAMEL-14915:
-----------------------------
    Summary: Why we're trying to create directory (FtpOperations.buildDirectory) when we have an FTPS route with no starting directory in camel ftps URI  (was: Why we're trying to create directory (FtpOperations.buildDirectory) when we have an FTPS route with no starting directory (means /))

> Why we're trying to create directory (FtpOperations.buildDirectory) when we have an FTPS route with no starting directory in camel ftps URI
> -------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-14915
>                 URL: https://issues.apache.org/jira/browse/CAMEL-14915
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-ftp
>    Affects Versions: 2.24.0
>         Environment: mac/linux
>            Reporter: Jin Feng
>            Priority: Major
>
> Hi,
> I setup a route using this FTPS URI:
> {noformat}
> ftps://filetransfer.bpost.be/?bridgeErrorHandler=true&connectTimeout=60000&delay=600000&disconnect=true&idempotent=true&idempotentKey=......&idempotentRepository=%23gfpIdempotentRepository&ignoreFileNotFoundOrPermissionError=true&localWorkDirectory=%2Ftmp%2F895c3952-e3f7-401f-b38f-055fcdf44301&maxMessagesPerPoll=0&move=archive&passiveMode=true&password=xxxxxx
> {noformat}
> You can see we didn't specify starting directory which we assume it would be defaulted to "/", but actually inside the code it gets defaulted to "" empty.
> Upon debugging, I see this behavior from camel [FtpConsumer.doStart()|https://github.com/apache/camel/blob/master/components/camel-ftp/src/main/java/org/apache/camel/component/file/remote/FtpConsumer.java#L77]:
> {code:java}
>                 try {
>                     connectIfNecessary();
>                     operations.buildDirectory(endpoint.getConfiguration().getDirectory(), true);
>                 } catch (GenericFileOperationFailedException e) {
>                     // log a WARN as we want to start the consumer.
>                     LOG.warn("Error auto creating directory: " + endpoint.getConfiguration().getDirectory() + " due " + e.getMessage() + ". This exception is ignored.", e);
>                 }
> {code}
> Now my ftp URI doesn't have starting directory, (which is optional according to [https://camel.apache.org/components/latest/ftps-component.html]), so the `getDirector()` here returns "" empty string. And then inside [FtpOperations.buildDirectory()|https://github.com/apache/camel/blob/master/components/camel-ftp/src/main/java/org/apache/camel/component/file/remote/FtpOperations.java#L359]:
> {code:java}
>             try {
>                 // maybe the full directory already exists
>                 success = client.changeWorkingDirectory(directory);
>                 if (!success) {
>                     log.trace("Trying to build remote directory: {}", directory);
>                     success = client.makeDirectory(directory);
>                     if (!success) {
>                         // we are here if the server side doesn't create
>                         // intermediate folders so create the folder one by one
>                         success = buildDirectoryChunks(directory);
>                     }
>                 }
>                 return success;
>             } finally {
> {code}
> It tries first to enter the "" directory, which failed. Then it tried to makeDirectory(""), which failed as well, after a very long timeout.
>  
> Of course we can use "autoCreate=false" to turn this behavior off. But my question is why do we want to try to autoCreate a directory when the directory string is actually "" empty?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)