fix(file-provider): invalidate lock tokens when file paths change. #10135
Merged
Conversation
Member
Author
|
/backport to stable-33.0 |
Member
Author
|
/backport to stable-4.0 |
This was referenced Jun 9, 2026
camilasan
force-pushed
the
bugfix/fpext-invalidate-lock-tokens
branch
from
e9fdd4c to
0a9390c
Compare
8 tasks
i2h3
approved these changes
Jun 12, 2026
camilasan
force-pushed
the
bugfix/fpext-invalidate-lock-tokens
branch
6 times, most recently
from
cddf4ea to
c9bd40b
Compare
Member
Author
|
/backport to stable-34.0 |
Contributor
|
Artifact containing the AppImage: nextcloud-appimage-pr-10135.zip Digest: To test this change/fix you can download the above artifact file, unzip it, and run it. Please make sure to quit your existing Nextcloud app and backup your data. |
WebDAV lock tokens are bound to the path they were issued for. When a parent folder moves, child lock tokens become stale and cause 412/423 upload failures. Clear tokens on rename propagation, server metadata sync, and upload lock errors. Assisted-by: Claude:claude-sonnet-4-5 Signed-off-by: Camila Ayres <hello@camilasan.com>
Assisted-by: Claude:claude-sonnet-4-5 Signed-off-by: Camila Ayres <hello@camilasan.com>
testParent404ReportsParentAsDeleted wrote metadata then awaited the enumerator without holding a Realm reference. Under parallel testing the in-memory store was freed before the enumerator reopened it on another thread, so the materialized-items query came back empty and the 404 parent was never reported deleted. Retain the Realm for each test lifetime. Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Camila Ayres <hello@camilasan.com>
camilasan
force-pushed
the
bugfix/fpext-invalidate-lock-tokens
branch
from
c9bd40b to
94a6df4
Compare
|
The backport to # Switch to the target branch and update it
git checkout stable-4.0
git pull origin stable-4.0
# Create the new backport branch
git checkout -b backport/10135/stable-4.0
# Cherry pick the change from the commit sha1 of the change against the default branch
# This might cause conflicts, resolve them
git cherry-pick 8ff950eb 457ae588 94a6df4c
# Push the cherry pick commit to the remote repository and open a pull request
git push origin backport/10135/stable-4.0Error: Failed to check for changes with origin/stable-4.0: No changes found in backport branch Learn more about backports at https://docs.nextcloud.com/server/stable/go.php?to=developer-backports. |
3 tasks
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resolves
This PR is related to #10134, better to merge it afterwards.
Stale WebDAV lock token cleared on path change — when an editor locks a file the server issues a token bound to that file's path. If the parent folder is renamed the token becomes invalid.
The next save attempt sends a stale If: header. The server rejects it with 412/423, and the user cannot save — they must manually copy the file elsewhere.
Summary
The code now clears it whenever a rename is detected: during sync, in the DB rename functions, and on upload errors 412 and 423.
Steps to test it
✅ Save succeeds — no further error dialog.
✅ The updated file appears in the web UI with the new content.
✅ The second save also succeeds.
Warning
Known limitation
...
When a folder is renamed on another client and LibreOffice has a file open inside it, saving may create a duplicate folder on the server at the old path. The File Provider extension does not coordinate renames through NSFileCoordinator, so macOS cannot notify open applications of the path change even if they implement NSFilePresenter. A proper fix requires the extension to wrap rename operations in NSFileCoordinator writes.
...
Our extension calls remoteInterface.move(...) (a WebDAV call) and then updates the local database. It does not go through NSFileCoordinator. So even if LibreOffice correctly registered as an NSFilePresenter, it still would not be notified — because our side isn't coordinating.
...
Our extension needs to use NSFileCoordinator when renaming items.
Checklist
AI (if applicable)