Yeah the current logic is that preMove will move the file first.
I guess we could consider acquiring the lock first, and then do the
preMove afterwards.
I have logged a ticket about this
https://issues.apache.org/jira/browse/CAMEL-6235
On Mon, Apr 1, 2013 at 8:37 PM, icemanltd <iceman...@hotmail.com> wrote:
> This behavior is causing an issue. I have specified
> preMove=temp/${exchangeID} with noop=true idempotent=false and
> readLock=rename. I was expecting that the lock would first be acquired, then
> the file moved to the preMove directory and then processing would begin and
> eventually end leaving the file in the preMove directory.
>
> If I ensure the file cannot be renamed (by opening the file in an editor
> that holds an exclusive lock on the file), I will get a number of empty
> directories being created under the temp directory. Finally when I release
> the lock the file will moved to the appropriate directory under temp.
>
> Am I doing something wrong, what is the behavior I should expect?
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Camel-file-component-preMove-creates-directory-before-read-lock-acquired-tp5728193p5730176.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cib...@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
