allthingssecurity opened a new pull request, #28031: URL: https://github.com/apache/camel/pull/28031
# Description [CAMEL-25723](https://issues.apache.org/jira/browse/CAMEL-25723) Since CAMEL-13399 (3.0) `ZipAggregationStrategy` writes into the zip file through a `ZipFileSystem` with `REPLACE_EXISTING` / `TRUNCATE_EXISTING`. When a later message of the group has the same entry name, the entry is replaced and the earlier content is lost, without a log. With the default strategy the entry name of a file is its name only, so a recursive file consumer that polls `a/orders.csv` and `b/orders.csv` produces a zip with one `orders.csv` holding the content of `b`. Change: before writing, `addFileToZip` / `addEntryToZip` look the name up in the open `ZipFileSystem`. If an entry with that name exists, the new entry is written under the first free name with ` (n)` before the extension: `orders.csv`, `orders (1).csv`, `orders (2).csv`. A leading dot is part of the name (`.profile (1)`), a name without an extension gets the number at the end (`README (1)`), and with `preserveFolderStructure` only the file name part changes. The free name is checked against the entries themselves, so a file really named `orders (1).csv` is not overwritten either. No exception is thrown, so batch completion works as before. Why a rename and not a failure: with `eagerCheckCompletion` the batch completion is checked before the aggregation, so a duplicate that is the last file of a poll completes the batch and then fails; the group with the first file would never complete and the duplicate would fail again at every poll. CAMEL-13399 was about speed (no rebuild of the whole zip per message); its follow-up commit added `TRUNCATE_EXISTING` so that shorter content does not leave the tail of an old entry. Both write options stay; the extra cost is one name lookup in the open `ZipFileSystem` per message whose name is free, and one more per earlier entry of the same name otherwise. `TarAggregationStrategy` is not changed: it rebuilds the tar per message and appends an entry under the same name, so the tar holds two `orders.csv` entries and a usual extraction keeps only the last one. It could get the same rename in a follow-up. What users can notice: entry names can now differ from the file names (or the `CamelFileName` header) when names repeat within a group. A note is added to the 4.24 upgrade guide, and a paragraph to the zipfile data format page (and its copy in camel-catalog). Tests: - New `ZipAggregationStrategySameFileNameTest` (7 tests): a recursive file route over only `a/orders.csv` and `b/orders.csv` with `completionFromBatchConsumer().eagerCheckCompletion()` (one zip with both contents); the same with a third file `c/other.csv`; the strategy called with two files named `orders.csv`; `useFilenameHeader=true` with two bodies named `report.txt`; four files named `orders.csv` plus one named `orders (1).csv`; names without an extension (`README`, `.profile`); and `preserveFolderStructure=true`, whose entries `a/orders.csv` and `b/orders.csv` are not renamed. - Without the change: 7 run, 6 failures (for example `expected: <[orders (1).csv=from B, orders.csv=from A]> but was: <[orders.csv=from B]>`). The `preserveFolderStructure` test passes on main as well; it is there to show that entries with different names are not renamed. - With the change the camel-zipfile tests pass: 56 run, 0 failures. `ZipSplitterRouteTest.testSplitterLargeFileWithSpoolEnabled` (the stream cache spool directory is not yet empty when it is checked) is flaky here with and without the change: it tests the zip splitter, does not use the aggregation strategy, and failed on main's code as well. What is not changed: `TarAggregationStrategy`, the zip/tar data formats and splitters, the entry names when they do not repeat. What was not run: the full root build. # 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-25723](https://issues.apache.org/jira/browse/CAMEL-25723). # 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 and tested camel-zipfile, including the formatter and import-sort plugins. 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]
