[
https://issues.apache.org/activemq/browse/CAMEL-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=54712#action_54712
]
Claus Ibsen commented on CAMEL-2058:
------------------------------------
Michael can you try 2.1-SNAPSHOT as we have fixed improved this. I think the
ticket was CAMEL-1963 or the likes (reported by Charles about some transaction
stuff)
> 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
>
> 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.
