[Feature]: Lock files when editing locally

[pmarini-nc]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• Nextcloud Server is running on 64bit capable CPU, PHP and OS.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

The file is not locked when edited locally

Steps to reproduce

1. Select a file and select the option edit locally from the 3-points menu
2. The file is correctly opened via the Desktop App. However the file lock status is not changed, even after a page refresh

Expected behavior

The file should be locked on step 2

Installation method

No response

Operating system

Other

PHP engine version

Other

Web server

Other

Database engine version

Other

Is this bug present after an update or on a fresh install?

Updated to a major version (ex. 22.2.3 to 23.0.1)

Are you using the Nextcloud Server Encryption module?

Encryption is Enabled

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

c.nc.com

List of activated Apps

c.nc.com

Nextcloud Signing status

c.nc.com

Nextcloud Logs

c.nc.com

Additional info

c.nc.com

[allexzander]

Not a bug but a feature request. The lock is not set even if the file is opened via file viewer locally.

[AndyScherzinger]

@juliushaertl I thought the server-side does lock the file first before triggering the edit locally, no?

[juliusknorr]

No, we only unlock the collaborative editing to free the file for the desktop client on the server. For locking we would not have a way to know when to unlock again, so either the lock would disappear after the timeout or it would last until manually removed by the user.

[allexzander]

@juliushaertl @AndyScherzinger
Then I guess this text https://nextcloud.com/blog/nextcloud-office-release-solves-document-compatibility-overhauls-knowledge-management/ needs to be adjusted as it is confusing in that part with "It then saves the file, locks it".

Nextcloud Office then closes the editor for the user and all other users currently editing it. It then saves the file, locks it in Files , syncs it to the desktop of the user and opens it with the local editor.

[AndyScherzinger]

I'd like to have @karlitschek's feedback on this from a product perspective - as in the locking should take place or not in case of edit locally and depending on that the blog post would need to be changed or.the exact locking behavior to be agreed on.

[karlitschek]

Very good question. I wasn't aware of the details here. @jancborchardt @jospoortvliet What do you all think? The lock will expire after 30min, correct?

[juliusknorr]

By default the lock never expires as introduced in nextcloud/files_lock#49 / nextcloud/files_lock#55 but can be configured by the admin.

Despite different timeouts I'd say the file should not get locked until it is actually opened by the desktop client. If the file is not synced or the client not installed there is no need to lock the file and we cannot detect either of the two on the server side unfortunately.

[allexzander]

Ok. So, this should be a feature for the desktop. Will need some time though, as it is not clear for example how to find out the file editing is finished on the desktop side and is not clear how to detect editing of non-office files (those for office apps create a special lock file so it can be detected, but this is not the case for txt files for example).

[maghog]

I think that for many this is one of the main new features in Hub 3. It gets both disappointing and embarrassing when it’s not working as expected (Nextcloud Office release solves document compatibility, overhauls knowledge management). Nextcloud has grown to be a very important platform for many organizations so I thing this should be high priority to solve.

[vagner-dias]

@allexzander I follow this issue for some time, and, If I may suggest, why not implement the possible/known use case of locking MSOffice files and afterwards evolve the locking to something more complex? I suggest that because some programs (Eg: Photoshop) does not even "lock" the file in the OS itself when you open it (try to open a file in Photohop, and, having the file open, try to delete it or rename it and see what happens) plus, if you investigate this in Google Drive or OneDrive, they did only implement the MSOffice lock feature so far.

Also, this article may give you some insights as to detect if a file is open in a specific folder: https://www.codeproject.com/Articles/18975/Listing-Used-Files

[tobiasKaminsky]

As far as I remember we agreed on manual lock in first place (without "edit locally") as otherwise it is hard to decide when to unlock.
For this "edit locally" I would go with 30min lock. The Desktop knows if the file is being opened via "edit locally".
Info should include this 30min default lock time, and also inform that user always can manually unlock, if needed.

I will put it on our board for next time.

[tobiasKaminsky]

@allexzander can you give a rough estimation how long this will take?

[allexzander]

@allexzander can you give a rough estimation how long this will take?

~4-5 days (implementation + testing + review)