File locks are not respected by nextcloud office or for core actions (rename, move, delete) by the same user

[tareko]

Hello,

I just upgraded to Nextcloud 28.0.2 from 26.x

File locking behaves unexpectedly and inconsistently with respect to actions by the user who did the file lock.

Steps to reproduce

Scenario 1: Correct behaviour while locking and editing MD files

• User A creates a .md file with contents
• File is locked
• File cannot be edited by either User A or User B while locked. This is expected behaviour.

Scenario 2: Unexpected behaviour while locking and editing NC Office files

• User A creates a .odt file with contents
• User A locks for external editing via NC desktop client. User A is actively editing file in Libreoffice.
• User B is not able to edit the file using NC Office. This is expected behaviour.
• User A is able to edit the file using NC Office, and save new contents, creating collision with local editor. This is new and unexpected behaviour.

Scenario 3: Expected behaviour when editing starts in NC Office

• User A creates a .odt file with contents
• User A starts editing the file inside Nextcloud Office
• File shows icon with "locked by Nextcloud Office"
• File cannot be renamed, deleted, or edited locally by User A or B (appears as read-only in NC desktop client). User B is able to edit inside Nextcloud Office if the file is shared with them. This is expected behaviour.

Scenario 3: Unexpected behaviour with file operations while file is locked.

• User A creates any file
• User A locks file using web interface
• User B cannot move, rename, etc. This is expected behaviour.
• User A can still move, rename, etc. This is unexpected behaviour.

In all cases, I see the icon and generate a file lock which does appear in the database table (oc_files_lock).

According to Zendesk's bug severity guidelines, this bug would be classified as "High" severity as the feature does not behave as expected and causes data loss in certain cases.

Any ideas on how best to proceed in terms of further debugging or resolving this bug?

Versions:
Collabora 23.05.8.4
NC 28.0.2
Files_lock 28.0.1

tarek : )

[joshtrichards]

Reproduction steps appear to be in forum post: https://help.nextcloud.com/t/nextcloud-28-0-2-ignores-file-locks-for-most-things-including-nextcloud-office/180844?u=jtr

[joshtrichards]

Are steps 8 & 9 also executed by User A?

If so I think the core bug is 4/5/6 (because I believe the owner can always override their own locks under the assumption they know what they're doing due to #73, but that's just my initial cursory take).

[tareko]

Are steps 8 & 9 also executed by User A?

If so I think the core bug is 4/5/6 (because I believe the owner can always override their own locks under the assumption they know what they're doing due to #73, but that's just my initial cursory take).

Yes, steps 8 and 9 are indeed executed by the owner.

Thank you so much for this hint. As a result, I went and looked at what the locking does from other users' perspective. What I found is that any other user is indeed blocked from editing / moving / renaming when the file is locked. That is to say that User B of Nextcloud cannot edit a file locked by User A.

This is great as it dramatically reduces the surface of this bug and narrows it down.

As such, I understand the logic of the change: "Trust user A to make changes to a file locked by user A, but don't trust user B".

Let's expand on this behaviour further: How does Libreoffice stop two opened copies of a document from being edited simultaneously? Using .~lock# files. In this case, because libreoffice is not both clients, Nextcloud Office does not know that libreoffice has opened the file, and so it allows user A to write over the file with no warning.

With your hint, I further explored the edges of this bug, and if a document is opened by Nextcloud Office, it is locked and not writeable to the Nextcloud desktop client shares (using an ubuntu desktop). This appears to be because Nextcloud Office does not behave as user A, but as its own user (user C).

I think the expected behaviour could be the following:

1. When a file is locked by user A and user A tries to make a modification such as rename, move, perhaps gently ask if this is desired despite the lock.
2. When a file is locked by user A, NC Office should not be able to open it for editing without unlocking it, even if that users is user A.

Because this is a relatively narrow case, I'm no longer sure when this behaviour entered NC. However, I do believe that it is dangerous behaviour anyhow as it is unexpected - if I lock a file, I'm expecting there to be no crashes in editing. Essentially, NC should mirror the behaviour of the MD editor in this sense.

I'm going to rewrite the above description to reflect how much narrower the bug seems to be, and to include reproduction steps. Thank you!