search

nextcloud / files_lock

GNU Affero General Public License v3.0
24 stars 8 forks source link

423 Locked when I am the lock owner, using NC Desktop #73

Closed marcotrevisan closed 1 year ago

marcotrevisan commented 2 years ago

Environment: NC Desktop 3.5.1, 3.5.2, 3.5.3, 3.5.4, 3.6.0 (mac OS). Server: 24.0.5 (Turnkey Linux, PHP8.0), updated all the apps.

STEPS TO REPRODUCE

  1. Lock a file using the client (or the server);
  2. The file gets successfully locked and it shows as locked by me;
  3. Edit that file; hit the "save" button; wait for the sync result

EXPECTED BEHAVIOUR

My client succeeds, all the other users' won't.

OBSERVED BEHAVIOUR

My client also won't suceed and gets a "423 Locked" error; if I unlock that file, it won't be synced (a conflict will be detected and I'll have to manually fix the situation).

I'm not sure this is a bug of the Desktop client so I posted it in this project. Apologies if I made an incorrect assumption.

mikaelsoriano commented 1 year ago

i have same issue :

After some digging, it seems it's because a missing header from webdav request (PUT) : https://github.com/nextcloud/files_lock/blob/45e4b68edd36934f71dae029462e6de577471ef6/lib/DAV/LockBackend.php#L78 https://github.com/nextcloud/files_lock/blob/45e4b68edd36934f71dae029462e6de577471ef6/lib/DAV/LockBackend.php#L79

When you remove "$userLock && " it works. Maybe it's not the solution but it explain why before we can update a locked file if we are lock owner.

I hope it can help.

marcotrevisan commented 1 year ago

In my humble opinion that condition seems too conservative: if we're able to get the lock, the lock type, and to check the lock owner against the current user, I don't think we need more info to take a decision. The user may decide to lock a file using the web UI and then edit it using any WebDAV client, that should be a "good" use case.

juliushaertl commented 1 year ago

I came to the same conclusion and just prepared a fix for this in #109