[
https://issues.apache.org/jira/browse/CAMEL-25948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-25948:
--------------------------------
Fix Version/s: 4.24.0
> camel-mina-sftp - with localWorkDirectory, the local work file of every
> consumed file is never deleted
> ------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25948
> URL: https://issues.apache.org/jira/browse/CAMEL-25948
> Project: Camel
> Issue Type: Bug
> Components: camel-mina-sftp
> Reporter: shashank
> Assignee: shashank
> Priority: Major
> Fix For: 4.24.0
>
>
> With {{localWorkDirectory}}, the consumer downloads each remote file into the
> local work directory and routes it as a {{java.io.File}}. The process
> strategy of all file consumers
> ({{GenericFileProcessStrategySupport.deleteLocalWorkFile}}, called on commit,
> rollback and abort) deletes the local work file named by the
> {{CamelFileLocalWorkPath}} header. The sftp, ftp, ftps, smb and azure-files
> operations set that header when they download into the local work directory.
> {{MinaSftpOperations.retrieveFileToFileInLocalWorkDirectory}} (main
> 9f839f4bcc9d) does not, so:
> * every file consumed by a mina-sftp endpoint stays in the local work
> directory for good, also when the exchange failed. The option is meant for
> very big files ("to avoid loading the content into memory"), so the disk
> fills up with a copy of everything the route ever consumed; a file is only
> replaced when a file of the same name is consumed again;
> * a file producer in the route copies the local work file to its target
> instead of moving it ({{FileOperations}} renames the local work file only
> when the header is set).
> The migration guide presents mina-sftp as a replacement of sftp and lists no
> difference for {{localWorkDirectory}}. The existing
> {{MinaSftpProducerConsumerFeaturesIT.testConsumerWithLocalWorkDirectory}}
> only checks the body; the sftp sibling {{SftpConsumerLocalWorkDirectoryIT}}
> checks that the local work file is deleted.
> *Fix*: {{MinaSftpOperations}} sets {{CamelFileLocalWorkPath}} to the local
> work file before it downloads the file, as {{SftpOperations}} does.
> *Behaviour change (upgrade guide entry)*: as with camel-sftp, where it is
> documented, the first file producer of the route now moves the local work
> file, while the message body still names it. A later step that reads the body
> again (a second file producer, {{convertBodyTo}}) fails because the file is
> gone, and another exchange that keeps the {{java.io.File}} body ({{wireTap}},
> {{seda}} without waiting, {{aggregate}}) finds it deleted when the exchange
> is done. Such routes must convert the body first, for example with
> {{convertBodyTo(byte[].class)}}.
> *Tests*: new {{MinaSftpConsumerLocalWorkDirectoryIT}} (embedded SFTP server
> of camel-test-infra-ftp, JUnit assertions as in the module); 4 fail on main:
> * {{localWorkFileIsDeletedWhenTheExchangeCompletes}}: {{The local work file
> should be deleted when the exchange is done ==> expected: <false> but was:
> <true>}};
> * {{localWorkFileIsDeletedWhenTheExchangeFails}}: same on rollback;
> * {{localWorkFileIsMovedToTheTargetOfAFileProducer}}: the local work file is
> still there after the file producer wrote its target;
> * {{aSecondFileProducerFindsTheLocalWorkFileMoved}} (pins the behaviour
> change): on main the second of two file producers succeeds, because the first
> one copied.
> A control passes on both:
> {{aBodyConvertedBeforeTheFileProducerCanBeWrittenTwice}} (the workaround).
> camel-mina-sftp tests and ITs with the fix: 308 run, 0 failures, 2 errors
> that are the same on main ({{MinaSftpConfigurationValidationIT}} OS user /
> ssh config user name fallback: the embedded server only accepts admin).
> *How it was found*: differential comparison of the remote file components
> that share the GenericFile / RemoteFile consumer (ftp, sftp, mina-sftp, smb,
> azure-files): the operations of every sibling except mina-sftp set
> {{CamelFileLocalWorkPath}} ({{SftpOperations}}, {{FtpOperations}},
> {{SmbOperations}}, {{FilesOperations}}). The IT above is the evidence.
> *Affected*: main, camel-4.23.x, camel-4.22.x and camel-4.18.x (the same
> method without the header; read, not run).
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
