fix (fileprovider): Consume lock ETags before File Provider content updates

[Rello]

Issue

Opening a Microsoft Word document creates a local Word lock file, which causes the File Provider extension to send a WebDAV LOCK request.

The server lock succeeded, but locking also changed the server ETag. The File Provider previously used that ETag for both:

• metadataVersion
• contentVersion

A lock-only ETag change therefore appeared to macOS as changed file contents. File Provider attempted to evict or replace the materialized document while Word still had it open, resulting in Resource busy, FP -2008, and a Finder cloud/error icon.

A second case occurred when the document was already locked by the same client. The LOCK response restored the local token but returned the existing ETag. Because the ETag did not change, macOS did not refresh its cached item metadata. The document remained advertised as non-writable and macOS applied the immutable uchg flag.

Fix

The implementation separates server metadata changes from actual file-content changes:

1. The ETag and token returned by LOCK are written directly to the target item's metadata.

2. A persisted fileProviderContentVersion retains the version of the file contents already known to File Provider. A lock-only ETag transition changes metadataVersion while leaving contentVersion unchanged. A successful upload advances both to the upload ETag.

3. After storing the lock token, the target item's synchronization timestamp is updated and the existing working-set change notifier is triggered. This immediately reports the updated lock capabilities to macOS.

4. The effective lock-ownership state is included in metadataVersion. Recovering a local token therefore refreshes the item even when LOCK returns the same ETag.

5. Both capabilities and fileSystemFlags recognize a locally owned token lock as writable. This prevents macOS from applying the immutable uchg flag.

A separate File Provider content version is required. Simply updating the ETag would also change contentVersion, causing macOS to treat the lock-only transition as changed file contents and attempt another replacement.

Dependent on nextcloud/NextcloudKit#249

Assisted-by: Codex:GPT-5

[i2h3]

And Nextcloud Desktop Client.xcworkspace/xcshareddata/swiftpm/Package.resolved contains wrong hashes.

[github-actions]

Artifact containing the AppImage: nextcloud-appimage-pr-10641.zip

Digest: sha256:cbf15bfbb01e95e146532261a73e251348da5a242e5abfbddeea1e3c411dbff9

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.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Rello]

@i2h3 problems are solved. It is building. and the test is confirmed that it is working as expected not.
you need an instance with file locking (not on the company instance)

[i2h3]

It works for me.

[Rello]

/backport to stable-34.0