If all calls are exclusively sequential, such a lock can only appear if a file is not closed after a write operation – and this is actually ensured by the implementation of all functions of the File Module.
If the calls are not strictly sequential (e.g. because RESTXQ is used, or because you have more than a single client), you may need to use query locks [1] in order to ensure that your code won’t be executed in parallel.
For more hints, we’ll need to look at your code and possibly your setup.
And about the write without append... it could happen on the 1st operation, but I noticed that in older code and just removed with write as I didn't know yet that we could have that issue with any write or append,.. but that opreation could have been in a recursive loop. So touched by the process more than once.
It only happens on the windows system. I tried making a small model... I couldn't reproduce... The fact that calling the same process may create a block at different lines makes it a bit aleatory.
I'll keep an eye out for patterns, but I've been looking for around a month now.
With luck, maybe someone else has a similar issue that can provide more clues.
Sorry, I doubt we’ll be able to track this down without code to reproduce this, or without a closer look at your system. Maybe it’s better to forward this to our commercial support?
If the process writes to a file like the example above, it typically crashes on the 1st write, not the following append.
So this should be reproducible even without append?
--