I don't think this is a platform issue. It could be that the filelock strategy as a whole is simply not compatible with the rename file strategy at all and what is currently there is just a hack pretending to do it correctly.
The error is happening because the lock is being released immediately and not during commit. During the commit it tries to release it again so you get the error. Nothing OS specific about that unless you are saying that on linux they just swallow the errors or flat out don't honor the locks. The problem here is I can't fix it on my end because the component I need access to(the rename strategy) is not a pluggable component. The main point is if you need to release a lock before you can rename a file, the rename strategy needs to do that in the correct order. Instead of rename file -> then release lock release lock -> then rename file I cannot fix this. Which means I cannot fix the strategy as a whole. The only thing I can do is hide the original problem without fixing it. The original problem being that the file lock strategy doesn't hold the lock till commit, it releases it immediately. What OS specific issue do you see here? -- View this message in context: http://camel.465427.n5.nabble.com/FileLockExclusiveReadLockStrategy-doesn-t-hold-lock-and-error-on-commit-tp5762668p5762706.html Sent from the Camel - Users mailing list archive at Nabble.com.
