[jira] [Commented] (CAMEL-3793) Try to copy file when rename fails

["Maria Iracheta (Commented) (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAMEL-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13117373#comment-13117373 ] 

Maria Iracheta commented on CAMEL-3793:
---------------------------------------

I can see why this change was made in the rename method of FileUtil, but this change has created a problem for us:
- Before: if a file was opened in Windows, the renaming method was not working, so the File was not being moved and therefore it was not being processed. It would fail and let the user know that the file could not be renamed.The file was not being processed.
- Now: if it cannot rename it, after 3 tries it will copy it (the processing of the file starts) and then fails to delete it, what means that it will be endlessly process the file until somebody realises.

Is it possible to make the feature of copy/delete instead of rename configurable? Or is there any way of preventing the endlessly processing of a File that is opened by a user in Windows that could come out of box with Camel File? Or should we implement our own thing?

                
> Try to copy file when rename fails
> ----------------------------------
>
>                 Key: CAMEL-3793
>                 URL: https://issues.apache.org/jira/browse/CAMEL-3793
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-core
>    Affects Versions: 2.6.0
>         Environment: Linux with NFS mounted directory pointing to a Windows 2008 Server shared directory
>            Reporter: Jean-Michel Morel
>            Assignee: Claus Ibsen
>             Fix For: 2.8.0
>
>
> I have a setup where I use file component to move files after being processed ou when processing fails.
> As I have no troubles neither on my development workstation neither on local directory on my linux environnement. It fails when the monitored directory is a NFS mounted directory pointing to a Windows 2008 Server shared directory.
> While it's not a camel bug, the generated logs are just useless because we can't get the reason of failure.
> Investigating the source code tells me that the File.renameTo method is used (with the three times try hack for Windows ;), so I can't get any further information on the reason.
> Could you implement a fallback strategy like copy the file and delete the original one ? (should it be made optional)
> To workaround this, I currently do the move operations manually by invoking the FileUtils.moveTo(...) from commons-io (which implements exactly the fallback method I described on renameTo failure).
> But, I have side effects as I'm forced to use the noop attribute.
> (in fact, it doesn't explain why the rename fails, but it works, and should it be a failure I'll get an explicit error message).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira