camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <j...@apache.org>
Subject [jira] Work started: (CAMEL-2058) File Component - Rename operations fail sometimes on certain filesystems (Windows)
Date Fri, 23 Oct 2009 09:03:52 GMT

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

Work on CAMEL-2058 started by Claus Ibsen.

> 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.


Mime
View raw message