[jira] [Created] (CAMEL-25948) camel-mina-sftp - with localWorkDirectory, the local work file of every consumed file is never deleted

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

shashank created CAMEL-25948:
--------------------------------

             Summary: 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


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)