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)
