-
Notifications
You must be signed in to change notification settings - Fork 752
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Linux Desktop client does not unlock files #5537
Labels
Comments
As a follow up - once the file is changed again after unlocking, the unlocked status will be synced correctly. But if the file is only unlocked and never changed again, the file stays locked locally. |
mgallien
added
2. to review
approved
bug approved by the team
bug
and removed
0. Needs triage
labels
Jun 23, 2023
mgallien
added a commit
that referenced
this issue
Jun 28, 2023
make sure that a file locked that would not be modifiable by the current client is read-only on storage also make sure we make a file read/write when modification can happen again Close #5537 Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
mgallien
added a commit
that referenced
this issue
Jun 29, 2023
make sure that a file locked that would not be modifiable by the current client is read-only on storage also make sure we make a file read/write when modification can happen again Close #5537 Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
mgallien
added a commit
that referenced
this issue
Jul 3, 2023
make sure that a file locked that would not be modifiable by the current client is read-only on storage also make sure we make a file read/write when modification can happen again Close #5537 Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
mgallien
added a commit
that referenced
this issue
Jul 10, 2023
make sure that a file locked that would not be modifiable by the current client is read-only on storage also make sure we make a file read/write when modification can happen again Close #5537 Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
mgallien
added a commit
that referenced
this issue
Jul 10, 2023
make sure that a file locked that would not be modifiable by the current client is read-only on storage also make sure we make a file read/write when modification can happen again Close #5537 Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
mgallien
added a commit
that referenced
this issue
Jul 11, 2023
make sure that a file locked that would not be modifiable by the current client is read-only on storage also make sure we make a file read/write when modification can happen again Close #5537 Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
mgallien
added a commit
that referenced
this issue
Jul 12, 2023
make sure that a file locked that would not be modifiable by the current client is read-only on storage also make sure we make a file read/write when modification can happen again Close #5537 Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
backportbot-nextcloud bot
pushed a commit
that referenced
this issue
Jul 12, 2023
make sure that a file locked that would not be modifiable by the current client is read-only on storage also make sure we make a file read/write when modification can happen again Close #5537 Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
camilasan
pushed a commit
that referenced
this issue
Jul 24, 2023
make sure that a file locked that would not be modifiable by the current client is read-only on storage also make sure we make a file read/write when modification can happen again Close #5537 Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug description
In my test cases the linux desktop client does add a lock if a shared file is locked via the web interface or via the desktop integration, but after releasing the lock, the lock on the client still exists. On windows this works in my tests. I also testes to thare a single file instead of a folder, but with the same behavior.
I am running server version "25.0.4 Enterprise" and linux client "3.7.4" on archlinux. The Windows test case is still on "3.6.4" but showing the correct behavior. Unfortunately I cannot update the client, as it is on a terminal server I don't have admin permission on and the client is installed via an AD group policy.
I am not sure if the lock feature is covered by our GEANT subscription, but if it helps I can drop a case into the customer ticket system as well.
Steps to reproduce
See attached the linux client log.
client_debug_log_lockfile.zip
Expected behavior
Releasing the lock removes the write lock on both linux and windows.
Which files are affected by this bug
lock-test.txt
Operating system
Linux
Which version of the operating system you are running.
Archlinux
Package
Distro package manager
Nextcloud Server version
25.0.4 Enterprise
Nextcloud Desktop Client version
3.7.4
Is this bug present after an update or on a fresh install?
Updated to a major version (ex. 3.3.6 to 3.4.0)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
Are you using an external user-backend?
Nextcloud Server logs
No response
Additional info
No response
The text was updated successfully, but these errors were encountered: