camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Lucier (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CAMEL-6082) File2 Component Over-normalizing A Files Absolute Path
Date Fri, 15 Feb 2013 16:09:13 GMT

     [ https://issues.apache.org/jira/browse/CAMEL-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jeremy Lucier updated CAMEL-6082:
---------------------------------

    Description: 
We have a component listening for a file to be dropped in a folder.  When the file lock attempts
to occur, it throws an exception saying the file doesn't exist. Same goes for moving the file
using preMove.

The reason being is some files that we're receiving have windows paths in their file name,
ex: "C:\logs\log.txt".  On our Linux box it is represented as: "/pickup/C:\logs\log.txt" (note
the slashes)

A standard Java File would handle that fine and properly identify the filename vs the path,
however GenericFile seems to want to normalize that to: "/pickup/c:/logs/log.txt". That normalization
causes camel to throw errors since that location/file doesn't exist.  

Untested, but in the GenericFile class, it looks like this might be the culprit:
 // we must normalize path according to protocol if we build our own paths
 String path = normalizePathToProtocol(getEndpointPath() + File.separator + getRelativeFilePath());
message.setHeader(Exchange.FILE_PATH, path);

Let me know if you need more information, thanks!

  was:
We have a component listening for file to be dropped in a folder.  When the file lock attempts
to occur, it throws an exception saying the file doesn't exist. Same goes for moving the file
using preMove.

The reason being is some files that we're receiving have windows paths in their file name,
ex: "C:\logs\log.txt".  On our Linux box it is represented as: "/pickup/C:\logs\log.txt" (note
the slashes)

A standard Java File would handle that fine and properly identify the filename vs the path,
however GenericFile seems to want to normalize that to: "/pickup/c:/logs/log.txt". That normalization
causes camel to throw errors since that location/file doesn't exist.  

Untested, but in the GenericFile class, it looks like this might be the culprit:
 // we must normalize path according to protocol if we build our own paths
 String path = normalizePathToProtocol(getEndpointPath() + File.separator + getRelativeFilePath());
message.setHeader(Exchange.FILE_PATH, path);

Let me know if you need more information, thanks!

    
> File2 Component Over-normalizing A Files Absolute Path
> ------------------------------------------------------
>
>                 Key: CAMEL-6082
>                 URL: https://issues.apache.org/jira/browse/CAMEL-6082
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-core
>    Affects Versions: 2.10.3
>         Environment: Linux
>            Reporter: Jeremy Lucier
>            Priority: Minor
>
> We have a component listening for a file to be dropped in a folder.  When the file lock
attempts to occur, it throws an exception saying the file doesn't exist. Same goes for moving
the file using preMove.
> The reason being is some files that we're receiving have windows paths in their file
name, ex: "C:\logs\log.txt".  On our Linux box it is represented as: "/pickup/C:\logs\log.txt"
(note the slashes)
> A standard Java File would handle that fine and properly identify the filename vs the
path, however GenericFile seems to want to normalize that to: "/pickup/c:/logs/log.txt". That
normalization causes camel to throw errors since that location/file doesn't exist.  
> Untested, but in the GenericFile class, it looks like this might be the culprit:
>  // we must normalize path according to protocol if we build our own paths
>  String path = normalizePathToProtocol(getEndpointPath() + File.separator + getRelativeFilePath());
> message.setHeader(Exchange.FILE_PATH, path);
> Let me know if you need more information, thanks!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message