camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Mathers (JIRA)" <>
Subject [jira] Created: (CAMEL-2058) File Component - Rename operations fail sometimes on certain filesystems (Windows)
Date Sat, 10 Oct 2009 00:26:52 GMT
File Component - Rename operations fail sometimes on certain filesystems (Windows)

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

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message