Claus Ibsen created CAMEL-26009:
-----------------------------------
Summary: camel-tarfile - marshal takes the entry size from the
CamelFileLength header, which fails after the body has changed
Key: CAMEL-26009
URL: https://issues.apache.org/jira/browse/CAMEL-26009
Project: Camel
Issue Type: Bug
Components: camel-tarfile
Affects Versions: 4.18.0, 4.22.0, 4.23.0
Reporter: Claus Ibsen
Fix For: 4.24.0
The tarFile marshal writes the size of the entry from the {{CamelFileLength}}
header, or else from {{available()}} of the stream ({{TarFileDataFormat}}, main
56aa5f4970a6, lines 67 and 81). Tar needs the exact size before the content,
and commons-compress fails when the content differs from it. The file consumer
sets {{CamelFileLength}} to the size of the file it read. So any route that
changes the body after a file consumer and then marshals tarFile fails.
Examples: decompressing the file first, or converting or transforming the body.
The iterators of zipFile and tarFile also copy the {{CamelFileLength}} of the
archive to each entry message, so tarring the entries of a split again fails
the same way (read from the code).
Checked on 4.24.0-SNAPSHOT with {{camel run}}: {{from: file:gzrun}} with a
64-byte {{plain.gz}}, then {{unmarshal: gzipDeflater}} (52 bytes), then
{{marshal: tarFile}}: {{java.io.IOException: Entry 'plain.gz' closed at '52'
before the '64' bytes specified in the header were written}}.
*Proposed change*: take the size from the body when it is known (bytes, a file,
a stream cache), or copy the body into a stream cache first, and use
{{CamelFileLength}} only when it matches.
_Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
