shashank created CAMEL-26081:
--------------------------------
Summary: camel-ftp, camel-mina-sftp - fileExist=Move: ${file:name}
in moveExisting is the path from the login directory with mina-sftp,
stepwise=false or a tempFileName, so the old file lands in a nested copy of the
endpoint path
Key: CAMEL-26081
URL: https://issues.apache.org/jira/browse/CAMEL-26081
Project: Camel
Issue Type: Bug
Components: camel-ftp, camel-mina-sftp, camel-sftp
Reporter: shashank
Assignee: shashank
With {{fileExist=Move}}, {{FtpDefaultMoveExistingFileStrategy}} (camel-ftp,
line 54) and {{SftpDefaultMoveExistingFileStrategy}} (camel-ftp-common, line
51; used by sftp and mina-sftp) set {{$\{file:name\}}} to the name they are
given and complete a relative result with the directory of the file (main
6a2f66ddec3e). With the default {{stepwise=true}} the ftp/sftp producer has
changed into the target directory and passes the bare name:
{{moveExisting=backup/$\{file:name\}}} for {{hello.txt}} in {{inbox/orders}}
gives {{inbox/orders/backup/hello.txt}}. The strategy gets the path from the
login directory instead with {{stepwise=false}} (ftp, ftps, sftp), always with
mina-sftp ({{MinaSftpOperations.doStoreFile}} line 1343 passes the full name;
its producer never changes directory), and with a {{tempFileName}} also with
{{stepwise=true}} ({{GenericFileProducer}} lines 237/259 pass the full target).
The result is then {{inbox/orders/backup/inbox/orders/hello.txt}}, and anything
that looks for the backup at {{inbox/orders/backup/hello.txt}} (where
{{stepwise=true}} puts it) does not find it; that includes the "there already
exists a file" check of {{eagerDeleteTargetFile=false}}, which looks at the
nested path, so a backup at {{inbox/orders/backup/hello.txt}} does not stop the
move (a second backup at the nested path is found and the producer fails as
intended). {{$\{file:name.noext\}}} and {{$\{file:name.noext.single\}}} read
the same {{CamelFileName}} header and nest the same way. A route moved from
{{sftp:}} to {{mina-sftp:}} with the documented token is affected without any
change.
*Fix*: both strategies set {{$\{file:name\}}} to the name of the file in its
directory, as with {{stepwise=true}} (the {{name.noext}} tokens follow);
{{$\{file:onlyname\}}}, {{$\{file:parent\}}}, {{$\{file:ext\}}}, the completion
and {{moveExisting=backup}} (without {{$\{...\}}}) are unchanged. For a
relative endpoint directory the result is then the same as with
{{stepwise=true}}. Upgrade guide entry (backups now land in
{{<dir>/backup/hello.txt}}).
*Tests*: new {{MinaSftpProducerMoveExistingFileNameIT}} (7 tests, 6 fail on
main, the {{$\{file:parent\}}} control passes),
{{SftpProducerMoveExistingFileNameIT}} and
{{FtpProducerMoveExistingFileNameIT}} (6 scenarios x stepwise true/false; 7 of
12 fail on main in each: all {{stepwise=false}} runs and the {{tempFileName}}
run with {{stepwise=true}}), for example {{File .../move/backup/hello.txt
should exist ==> expected: <true> but was: <false>}}. With the fix camel-ftp
211 run / camel-mina-sftp 49 run (unit tests plus move-existing and stepwise
ITs), 0 failures.
*Not changed* (separate follow-ups): camel-smb has the same strategy and
nesting ({{SmbDefaultMoveExistingFileStrategy}} line 51, {{SmbOperations}} line
475; its tests need a Samba container); the file component strategy nests the
same way; an absolute endpoint directory (for example
{{mina-sftp://host//data/inbox}}, or {{stepwise=false}}) still puts the backup
below the login directory ({{data/inbox/backup/hello.txt}}), while sftp with
{{stepwise=true}} uses {{/data/inbox/backup/hello.txt}}; the completion is a
plain string prefix check, so {{moveExisting=inbox-old/$\{file:name\}}} for a
file in {{inbox}} is not completed with {{stepwise=false}}. The last two are
the same on main.
*How it was found*: differential testing of sftp (JSch), mina-sftp and ftp with
the same producer scenarios.
*Affected*: main and camel-4.22.x (mina-sftp since 4.19); the ftp/sftp
{{stepwise=false}} and {{tempFileName}} cases also on older lines. Read, not
run.
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
