Problem overview and supposed purpose of the "lock_timeout" feature
When the "lock_timeout" parameter (by default non-existent, potentially leaving a file locked for eternity, but applicable via an OCC command), the unlocking generated by this parameter after a certain number of minutes takes place no matter what, even if there are still people in it.
If I've correctly understood (interpreted) the purpose of this parameter, it is used to unlock the file after a certain time:
if the file has been locked manually, but the person forgot to unlock it (manually)
if the file has been locked automatically on opening, but for some unknown reason has not been closed "properly", and the automatic unlock signal has not been received and executed.
So, in theory, this parameter is a good way of guaranteeing that files will be unlocked in the event of an oversight or technical problem.
Description of the problem making "lock_timeout" very annoying, even dangerous
The BIG problem, in the real world, is that the parameter takes no account of the presence of people in the file, and orders the file to be locked regardless of the situation.
Let's imagine that the parameter is set to 15 minutes and that someone has entered the file to modify it. After 15 minutes, while the file is still occupied by this person (and perhaps others as well), unlocking occurs ... and the potential trouble starts here. From that moment on, while the user thought he was "protected" by the automatic locking system, he isn't and, without understanding why, he will possibly be confronted with a version conflict reported by his synchronization client (because another person has opened and edited the "unlocked" file from his computer).
I'll leave you to imagine this in the context of manual locking.
Then, to get around this problem, you could set the lock_timeout to 2h for example, but this is not a solution because :
in the professional world, editions lasting more than 2 hours are frequent
the advantage of lock_timeout is that it doesn't take hours to unlock files that have been blocked (due to an oversight or a technical problem).
What would be the appriate behavior ot the "lock_timeout" feature ?
I believe, based on the various tests I've carried out, and my experience "in the field" in a "daily" professional environment, that the lock_timeout countdown should ONLY start when there's no one left in the file. If, before the end of the countdown, someone opens the file again, the countdown must stop, and will only restart when everyone has left the file.
Hello,
Problem overview and supposed purpose of the "lock_timeout" feature
When the "lock_timeout" parameter (by default non-existent, potentially leaving a file locked for eternity, but applicable via an OCC command), the unlocking generated by this parameter after a certain number of minutes takes place no matter what, even if there are still people in it.
If I've correctly understood (interpreted) the purpose of this parameter, it is used to unlock the file after a certain time:
So, in theory, this parameter is a good way of guaranteeing that files will be unlocked in the event of an oversight or technical problem.
Description of the problem making "lock_timeout" very annoying, even dangerous
The BIG problem, in the real world, is that the parameter takes no account of the presence of people in the file, and orders the file to be locked regardless of the situation.
Let's imagine that the parameter is set to 15 minutes and that someone has entered the file to modify it. After 15 minutes, while the file is still occupied by this person (and perhaps others as well), unlocking occurs ... and the potential trouble starts here. From that moment on, while the user thought he was "protected" by the automatic locking system, he isn't and, without understanding why, he will possibly be confronted with a version conflict reported by his synchronization client (because another person has opened and edited the "unlocked" file from his computer).
I'll leave you to imagine this in the context of manual locking.
Then, to get around this problem, you could set the lock_timeout to 2h for example, but this is not a solution because :
What would be the appriate behavior ot the "lock_timeout" feature ?
I believe, based on the various tests I've carried out, and my experience "in the field" in a "daily" professional environment, that the lock_timeout countdown should ONLY start when there's no one left in the file. If, before the end of the countdown, someone opens the file again, the countdown must stop, and will only restart when everyone has left the file.