with files client automated locking we need a sane default value

[mgallien]

would prevent having locks with 0 tiemout because the config value is never changed on server

there will be more locks since desktop files client will automatically lock office files making this more visible

[mgallien]

discussed with @allexzander
following tests of the release candidate of desktop client next feature release

[mgallien]

related change on desktop files client nextcloud/desktop#6027

[juliusknorr]

I tend to agree that having a somewhat reasonable lock timeout is better, especially if automatic locking on clients happens more often now. We used to have this in the past but switched to the infinite one per discussion in #49.

One issue with the default timeout is that if users intentionally lock because they go on a longer flight for example, then the lock would just timeout and no longer prevent other users from editing. However this seems more like and edge case compared to day to day usage and is still safeguarded by versions that one could restore to get changes back. Also admins might still be able to unlock anyways. There should also be a conflict dialog anyways so all predictable behaviour.

Fine with me but involving @AndyScherzinger and @tobiasKaminsky as involved in the initial decision.

[juliusknorr]

Change seems good to me, waiting for more comments before approving regarding changing the default

[mgallien]

I tend to agree that having a somewhat reasonable lock timeout is better, especially if automatic locking on clients happens more often now. We used to have this in the past but switched to the infinite one per discussion in #49.

One issue with the default timeout is that if users intentionally lock because they go on a longer flight for example, then the lock would just timeout and no longer prevent other users from editing. However this seems more like and edge case compared to day to day usage and is still safeguarded by versions that one could restore to get changes back. Also admins might still be able to unlock anyways. There should also be a conflict dialog anyways so all predictable behaviour.

Fine with me but involving @AndyScherzinger and @tobiasKaminsky as involved in the initial decision.

The fact that 0 means infinite was definitely a misunderstanding from us desktop files client team
We always assumed that 0 meant 0
We may also adjust our code a little bit more to have proper handling of the 0 value @tobiasKaminsky ?

[mgallien]

another related fix for desktop client
nextcloud/desktop#6059

[AndyScherzinger]

Can you give me some additional context on why you would change this away from infinite? That just works around the problem of improper unlocking or at least that is how it sounds to me but I might be completely wrong here.

Also checking the referenced decision, I expect:

• clients aren't handling server-unlock via timeouts (yet)
• admin-unlock is not implemented (yet)

[mgallien]

assuming that the main reason for this PR was a misunderstanding over the use of 0 as an infinite timeout, I would like to close this one in favor of #175 (just improving the API doc around the lock-timeout)

[mgallien]

Can you give me some additional context on why you would change this away from infinite? That just works around the problem of improper unlocking or at least that is how it sounds to me but I might be completely wrong here.

Also checking the referenced decision, I expect:

* clients aren't handling server-unlock via timeouts (yet)

desktop client will schedule a server sync font expired locks to ensure we do not miss files being unlock after the timeout expired
that was not properly handling the 0 value

but as I said, I am all for closing this one in favor of doc improvements