Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.0.0
-
None
-
Sun JDK 1.6_16, Eclipse Gallileo, Spring 2.5, Camel 2.0.0, Windows XP SP2, McAfee VirusScan
Description
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.
Attachments
Issue Links
- is related to
-
CAMEL-3793 Try to copy file when rename fails
-
- Resolved
-