allthingssecurity opened a new pull request, #28466: URL: https://github.com/apache/camel/pull/28466
# Description [CAMEL-25948](https://issues.apache.org/jira/browse/CAMEL-25948) With `localWorkDirectory`, the consumer downloads each remote file into the local work directory and routes it as a `java.io.File`. When the exchange is done (commit, rollback or abort), `GenericFileProcessStrategySupport.deleteLocalWorkFile` deletes the local work file named by the `CamelFileLocalWorkPath` header. `SftpOperations`, `FtpOperations`, `SmbOperations` and `FilesOperations` (azure-files) set that header when they download into the local work directory. `MinaSftpOperations.retrieveFileToFileInLocalWorkDirectory` does not. As a result: - every file a mina-sftp endpoint consumes stays in the local work directory for good, also when the exchange failed. The option is meant for big files, so the disk fills up with a copy of everything the route 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). Changes: - `MinaSftpOperations` sets `CamelFileLocalWorkPath` to the local work file before it downloads the file, as `SftpOperations` does. - Upgrade guide (4.24): as with camel-sftp, the first file producer of the route now moves the local work file, and 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)`. camel-sftp documents the same ("the local file is deleted", "use a rename instead of a file copy" in the ftp component page). Users who cleaned the local work directory themselves can stop doing so. - No option or generated file change. - Backport: camel-4.23.x, 4.22.x and 4.18.x have the same method without the header (read, not run). Not changed: when the download itself fails, the partly written `.inprogress` file stays until the same file is downloaded again (sftp deletes it at once). The next download of that file deletes it first, so it does not accumulate. Tests: - New `MinaSftpConsumerLocalWorkDirectoryIT`, on the embedded SFTP server of camel-test-infra-ftp like the other mina-sftp ITs, with JUnit assertions as in the module. It mirrors `SftpConsumerLocalWorkDirectoryIT` of camel-ftp, which checks that the local work file is deleted. 4 tests fail on main: - `localWorkFileIsDeletedWhenTheExchangeCompletes`: `The local work file should be deleted when the exchange is done ==> expected: <false> but was: <true>`. - `localWorkFileIsDeletedWhenTheExchangeFails`: the same after a rollback. - `localWorkFileIsMovedToTheTargetOfAFileProducer`: the local work file is still there after the file producer wrote the target. - `aSecondFileProducerFindsTheLocalWorkFileMoved` pins the behaviour of the upgrade guide entry: the second of two file producers fails (`The second file producer should fail ==> expected: <true> but was: <false>` on main, where the first one copied). - Control that passes on main and with the fix: `aBodyConvertedBeforeTheFileProducerCanBeWrittenTwice` (the workaround of the guide entry). - camel-mina-sftp tests and ITs (run locally through surefire, embedded server): 308 run, 0 failures, 8 skipped. 2 errors in `MinaSftpConfigurationValidationIT` (`testMissingUsernameUsesOsUserFallback`, `testMissingUsernameUsesSshConfigFallback`) are the same on main: the embedded server only accepts the user `admin`, and my OS user name is used. The formatter and import-sort plugins ran. I built offline with `-Dasm-version=9.11 -Djsch-version=2.28.7` because asm 9.11.1 and jsch 2.28.8 were not in my local repository, with camel-file, camel-ftp-common and camel-ftp built in the same reactor. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it): [CAMEL-25948](https://issues.apache.org/jira/browse/CAMEL-25948). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built camel-mina-sftp and ran its tests and ITs, including the formatter and import-sort plugins. No generated file changes. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
