[
https://issues.apache.org/activemq/browse/CAMEL-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=54938#action_54938
]
Claus Ibsen commented on CAMEL-2058:
------------------------------------
*Issue #2*
I guess it depends on the OS. On my Mac the rename operation will succeed even
if the target file exists. So that could be an Windows OS issue, that wont
allow renaming a file when the target filename already exists.
But Camel should of course use the {{fileExist}} option in any case
> File Component - Rename operations fail sometimes on certain filesystems
> (Windows)
> ----------------------------------------------------------------------------------
>
> Key: CAMEL-2058
> URL: https://issues.apache.org/activemq/browse/CAMEL-2058
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 2.0.0
> Environment: Sun JDK 1.6_16, Eclipse Gallileo, Spring 2.5, Camel
> 2.0.0, Windows XP SP2, McAfee VirusScan
> Reporter: Michael Mathers
> Assignee: Claus Ibsen
> Fix For: 2.1.0
>
>
> On Windows (don't know if there are other platforms that suffer from this
> problem), the file component fails to successfully rename files with the
> File.renameTo operation. It fails when the rename is performed immediately
> after closing a file. On Windows this usually indicates that some other
> process has the file open. This occurs due to things like Virus scanners
> which keep the file open for very short periods of time. Given a slight
> pause the rename would succeed.
> This is a serious problem which effectively makes useless options like
> "tempPrefix" in the File Producer and "localWorkDirectory" with the FTP
> Consumer. Workarounds like "disable your virus scanner" don't cut it for
> everyone (me specifically) as I'm system privilege restricted from doing so,
> and even then, there's no guarantee that other windows processes might not do
> similar things (file indexers, etc).
> The Java spec doesn't define the behavior of the rename operation and
> specifically says that this can vary from implementation to implementation /
> filesystem to filesystem. Second, rename doesn't say why it fails, it merely
> returns false which is very unhelpful.
> A couple ways to fix:
> 1). Provide an option to disable this optimization. ie, a
> "alwaysCopyInsteadOfRename" or something (clean, simple, easy).
> This would be a simple fix. More or less just a few clauses/tests in
> GenericFileProducer around any "is local" checks....
> 2). Attempt a copy instead if the rename fails
> - maybe after a brief pause
> - maybe even after a number of rename attempts
> - maybe watch to see the file is closed prior to a rename attempt.
> Rename operation failures may affect other things as well like certain
> locking schemes.
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4167147
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
