[
https://issues.apache.org/jira/browse/CAMEL-24415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18107075#comment-18107075
]
Andrea Cosentino commented on CAMEL-24415:
------------------------------------------
*Design analysis, and a request for a maintainer read before implementing.*
Tracing where the value actually comes from changes the picture again, so the
earlier "path vs name" framing needs refining too.
FileConsumer.asGenericFile builds the value like this:
{code:java}
answer.setFileNameOnly(file.getName());
...
if (path.getParent() != null) {
answer.setRelativeFilePath(path.getParent() + File.separator +
file.getName());
} else {
answer.setRelativeFilePath(path.getName());
}
// the file name should be the relative path
answer.setFileName(answer.getRelativeFilePath());
{code}
So in camel-file the file name *is* deliberately the relative path - it carries
directory components when recursive=true. CamelFileNameOnly is the true single
component, and the probe on this issue showed it keeps the backslashes intact
while CamelFileName does not.
*Where the rewrite is and is not load-bearing.*
The consumer composes the value with File.separator and file.getName(), so it
is already correct for the platform before setRelativeFilePath() runs. The same
holds for the remote components: RemoteFile, SmbFile and FilesEndpoint all
return '/' from getFileSeparator(), and their clients report '/'-separated
paths, so normalizePathToProtocol is a no-op on the consumer path there too.
Where it *is* load-bearing is the producer path - a route-supplied
CamelFileName written with Windows separators being used against a POSIX or
remote target. That case should keep normalising.
*Proposed shape:* keep normalizePathToProtocol on the route-supplied path, and
stop applying it to consumer-derived values, which are already
platform-correct. Concretely that means a raw setter used by the consumers
(FileConsumer.asGenericFile and the remote equivalents) that assigns
relativeFilePath/fileName without rewriting, leaving the existing setters
unchanged for producer use.
A regression test should assert that a consumed file whose name legitimately
contains backslashes reports CamelFileName equal to CamelFileNameOnly, and that
a producer given CamelFileName with Windows separators still writes to the
nested path.
*Why I am not just pushing this.* camel-file is the most widely used component
in the project and the change touches how every consumed file is named. The
exploitability is already bounded - the producer refuses the resulting path
because jailStartingDirectory defaults to true - so there is no urgency that
justifies me picking the seam unilaterally. I would rather a maintainer confirm
the raw-setter shape is the one they want before I write it.
> camel-file - normalizePathToProtocol turns a backslash in a legal POSIX file
> name into a path separator
> -------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24415
> URL: https://issues.apache.org/jira/browse/CAMEL-24415
> Project: Camel
> Issue Type: Bug
> Components: camel-file
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Major
> Fix For: 4.23.0
>
>
> GenericFile.normalizePathToProtocol() rewrites both separators
> unconditionally:
> path = path.replace('/', getFileSeparator());
> path = path.replace('\\', getFileSeparator());
> and is applied in setFileName() and setRelativeFilePath(), and when building
> the CamelFilePath header.
> On POSIX a backslash is a legal character in a file name, so a
> single-component file name that contains backslashes is rewritten into a
> multi-component relative path. Downstream strategies that resolve the file
> name against the endpoint directory (delete, move, done-file/marker handling)
> then operate on a different path than the one that was actually read.
> Proposal: only translate the separator that is not legal on the current
> platform (FileUtil.normalizePath() already does exactly this - on POSIX it
> maps '\\' to '/' only when running on Windows), or keep the consumed file
> name as an opaque single component. Needs a regression test on POSIX using a
> file whose name legitimately contains backslashes.
> Before changing behaviour, confirm on a POSIX box which of the
> delete/move/marker strategies actually resolve out of the starting directory,
> so the fix targets the right layer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
