Thanks Mohan, I fully agree with you - besides one point:
Always checking the return value of the renameTo(...) function call is of no
use if you can't rely on Windows having completed, flushed and unlocked
everything to disk before returning this value.
My experience is that even if the return value is TRUE, the underlying
Windows rename operation (or the unlocking) still is incomplete.
The correct call should have an operating system dependent option such as
"renameToEx(..., WRITE_THROUGH=TRUE)" or
"renameToEx(...,
TELL_WINDOWS_TO_NOT_RETURN_UNLESS_EVERYTHING_IS_FLUSHED_AND_UNLOCKED)"
Unfortunately - making heavy use of frameworks (Camel ->
org.apache.commons...FileUtils, Smooks, ..) - I have no direct influence on
what happens with IO calls, retry counts, close operations e.g. ...)
My camel route is as simple as this:
from( "file://{{w.inbox}}?"
+ "initialDelay={{w.polling.init.msec}}" //15000
+ "&delay={{w.polling.msec}}" //25000
+ "&preMove={{w.inbox.pre}}"
+ "&move={{w.backup}}/${date:now:yyyy-MM-dd}/${file:onlyname}"
+ "&moveFailed={{w.error}}/${date:now:yyyy-MM-dd}/${file:onlyname}"
+ "&maxMessagesPerPoll={{w.inbox.maxMsgPerPoll}}" //10
)
.log( LoggingLevel.INFO, "imp_protocol", "Importiere Daten :
${file:onlyname}" )
.convertBodyTo( StreamSource.class )
.to( "smooks://smooks-config.xml" )
;
--
View this message in context:
http://camel.465427.n5.nabble.com/File-renaming-problems-under-Windows-tp5719484p5719581.html
Sent from the Camel - Users mailing list archive at Nabble.com.
