[jira] [Created] (CAMEL-26009) camel-tarfile - marshal takes the entry size from the CamelFileLength header, which fails after the body has changed

["Claus Ibsen (Jira)" <ji...@apache.org>]

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)