[
https://issues.apache.org/jira/browse/CAMEL-25726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-25726 started by shashank.
----------------------------------------
> camel-azure-files - the producer creates the file with the size from a stale
> CamelFileLength header, so a body the route made shorter is stored with zero
> bytes at its end
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25726
> URL: https://issues.apache.org/jira/browse/CAMEL-25726
> Project: Camel
> Issue Type: Bug
> Components: camel-azure
> Reporter: shashank
> Assignee: shashank
> Priority: Major
>
> The Azure Files producer creates the remote file with its final size and then
> writes the body into it ({{FilesOperations.storeFile}}, main 826a664c5f16,
> lines 486-497 and 508). When a {{CamelFileLength}} header is present, its
> value is used as that size, whatever the body is:
> {code:java}
> var knownLength = exchange.getIn().getHeader(Exchange.FILE_LENGTH,
> Long.class);
> if (knownLength != null) {
> is = exchange.getIn().getMandatoryBody(InputStream.class);
> length = knownLength.intValue();
> {code}
> Every file-family consumer (file, ftp, sftp, smb, azure-files) sets
> {{CamelFileLength}} to the length of the consumed file, and the header stays
> on the message when the route changes the body. So a route like
> {code:java}
> from("file:in").split(body().tokenize("\n")).to("azure-files://account/share/dir?fileName=${exchangeId}.txt&...");
> {code}
> (or a transform / marshal / enrich between the two) creates each Azure file
> with the size of the whole input file and writes only the shorter body: the
> stored file ends with zero bytes, and the exchange completes normally. A body
> longer than the header fails at the write past the end of the file (read, not
> run). The header is also narrowed with {{intValue()}}.
> CAMEL-25167 made the same choice for the other file / object-storage
> producers: their length helper {{PayloadHelper.getBodyLength}} "deliberately"
> does not use {{CamelFileLength}}, "as it can be stale once the route changed
> the body". camel-azure-files was not part of that change.
> The component page says the producer is "optimized for" an {{InputStream}}
> with {{CamelFileLength}} set, and for {{byte[]}}; it does not say that the
> header also overrides the length of a {{byte[]}} or {{String}} body.
> h3. Reproduction
> New {{FilesOperationsStoreLengthTest}} (mocked {{ShareDirectoryClient}} /
> {{ShareFileClient}}, no Azure service): {{storeFile}} with a 3-byte body and
> {{CamelFileLength=10}} must create a 3-byte file; with a 20-character String
> body and {{CamelFileLength=10}} a 20-byte file. On main the file is created
> with 10 bytes in both ({{expected: <3> but was: <10>}}, {{expected: <20> but
> was: <10>}}, 3 of 3 runs). A third test (a stream of unknown length with a
> correct header is streamed with the header length) passes on main and with
> the fix; it guards the documented streaming case.
> h3. Proposed fix
> The size is the length of the body when it is known without reading it
> ({{PayloadHelper.getBodyLength}}: a file or wrapped file, {{byte[]}}, a
> cached stream, a byte-array or file stream); a body that is not a stream is
> converted to {{byte[]}}; {{CamelFileLength}} is only used for a stream whose
> length cannot be known otherwise, as documented. The size is passed as a
> {{long}}. Upgrade note in the 4.24 guide and a paragraph on the component
> page.
> With the fix the camel-azure-files tests pass: 31 run, 0 failures, 0 errors,
> 0 skipped.
> Not changed: {{storeFileDirectly}} writes {{payload.getBytes()}} in the
> platform charset (possible follow-up).
> Affected: main (tested); camel-4.23.x, camel-4.22.x and camel-4.18.x have the
> same code (read, not run).
> Duplicate check (2026-10-17): JIRA text "azure-files" with "length" / "size"
> / "zero": only CAMEL-25167 (other components); GitHub pull requests
> "azure-files length", "FilesOperations": none about this.
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
