Federico Mariani created CAMEL-26672:
----------------------------------------
Summary: camel-jsch - the scp producer with checksumFileAlgorithm
writes the file and then fails to write the checksum file
Key: CAMEL-26672
URL: https://issues.apache.org/jira/browse/CAMEL-26672
Project: Camel
Issue Type: Bug
Components: camel-jsch
Affects Versions: 4.18.5, 4.23.0, 4.22.2
Reporter: Federico Mariani
h3. Problem
With {{checksumFileAlgorithm}} (for example {{md5}}) the scp producer writes
the file, and then the exchange fails with
{{GenericFileOperationFailedException: Failed to write file <name>.md5}}.
The checksum file is written by {{GenericFileProducer.writeChecksumFile}}
through {{ScpOperations.storeFileDirectly}}
({{components/camel-jsch/src/main/java/org/apache/camel/component/scp/ScpOperations.java}}
line 164 on main, commit 2d97a2141484). Unlike {{storeFile}} (line 104),
{{storeFileDirectly}}:
* opens the {{exec}} channel, but never sets the scp command
({{channel.setCommand(getScpCommand(cfg, file))}}) and never connects it
({{channel.connect(timeout)}}), so the write on the channel fails;
* never disconnects the channel it opened, and does not clear the {{channel}}
field;
* does not resolve the remote name with {{getRemoteFile(name, cfg)}}, as
{{storeFile}} does.
On main, {{writeChecksumFile}} always calls {{storeFileDirectly}} when
{{checksumFileAlgorithm}} is set (CAMEL-25906), so every exchange of an scp
producer with that option fails. The 4.24 upgrade guide entry "camel-ftp,
camel-mina-sftp, camel-jsch, camel-smb, camel-azure-files -
checksumFileAlgorithm writes a checksum again" says scp now writes the checksum
file.
On camel-4.22.x and camel-4.18.x, {{writeChecksumFile}} calls
{{storeFileDirectly}} only when the message already has a {{CamelFileChecksum}}
header (for example set by an earlier file producer of the route), and
{{storeFileDirectly}} is the same there, so such an exchange fails the same way
(read from the code).
h3. How to reproduce
Measured with a test against the embedded SSH server of the camel-jsch tests
({{ScpServerTestSupport}}), on a branch based on main 2d97a2141484: a route
sends {{Hello World}} to
{{scp://localhost:<port>/...?username=...&password=...&knownHostsFile=...&checksumFileAlgorithm=md5}}
with {{CamelFileName=hello.txt}}.
* {{hello.txt}} is written with the content {{Hello World}};
* the exchange then fails with {{GenericFileOperationFailedException: Failed to
write file .../hello.txt.md5}}.
Without {{checksumFileAlgorithm}} the same route succeeds (control). The
missing {{setCommand}}/{{connect}} and the missing disconnect are read from the
code.
h3. Proposed change
* Let {{storeFileDirectly}} use the same channel handling as {{storeFile}}:
resolve the name with {{getRemoteFile}}, set the scp command, connect with the
configured timeout, write, and disconnect in a {{finally}}. A shared private
method for both would avoid the two paths drifting apart again.
* Add a test with the embedded SSH server: with {{checksumFileAlgorithm=md5}}
the exchange succeeds, {{hello.txt.md5}} holds the hex MD5 of the uploaded
bytes, and the {{CamelFileChecksum}} header is set; also a test for a name in a
sub directory.
h3. Impact / upgrade
* No option or default changes. scp with {{checksumFileAlgorithm}} then works
as the 4.24 upgrade guide already describes.
* For camel-4.22.x and camel-4.18.x, the same fix makes the header path work; a
backport candidate.
h3. Related
* CAMEL-25906 (4.24.0, commit c10c5f832558): the remote file producers write
the checksum file again; it lists scp among them, and added the upgrade-guide
entry above. For scp the checksum file still fails because of
{{storeFileDirectly}}.
* CAMEL-22846: added {{storeFileDirectly}} to the scp operations (checksum
file).
* CAMEL-26066: found while fixing it (scp file names with a line feed); that
fix also checks the name in {{storeFileDirectly}}, but does not change how the
channel is opened.
_Claude Code on behalf of Federico Mariani_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
