[Bug]: macOS File Provider does not remove local items after server-side deletion

[RomanovVIII]

Bug description

Nextcloud Desktop in macOS File Provider mode receives a server-side change but does not remove from Finder a file that has already been deleted from the server.

The issue is reproducible with both fully downloaded files and cloud placeholders whose contents have never been downloaded to the Mac.

Environment

• macOS: 26.6.2, Apple Silicon
• Nextcloud Desktop Client: 34.0.2
• Installation method: official installer for macOS 13 and later
• Mode: File Provider / Virtual Files
• Nextcloud Server: 33.0.7.1, Nextcloud AIO
• notify_push: installed and working
• Server-side encryption is not used for the test files

Steps to reproduce

1. Create a test Markdown file directly on the server through WebDAV.
2. Wait for the file to appear in Finder on the Mac.
3. Do not open the file. Use fileproviderctl evaluate to confirm:
   • isDownloaded = 0
   • isKeepDownloaded = 0
   • isUploaded = 1
   • isTrashed = 0
4. Delete the file directly from the server through WebDAV.
5. Confirm that the server returns DELETE 204.
6. Check the server path again and confirm that it returns 404.
7. Observe the file in Finder.

Expected behavior

After the server-side deletion, the local placeholder or downloaded file should disappear from Finder.

Actual behavior

The file remains in Finder indefinitely.

After the server-side deletion, fileproviderctl evaluate continues to report the previous item:

• the previous itemIdentifier;
• isDownloaded = 0 or 1, depending on the test;
• isUploaded = 1;
• isTrashed = 0;
• the previous version/ETag.

Restarting Nextcloud Desktop, restarting FileProviderExt, and fully rebooting macOS do not resolve the problem.

Additional findings

• Creating a file on the server propagates to the Mac, sometimes after a delay of approximately one minute.
• Modifying a file on the server propagates to the Mac.
• Creating, modifying, and deleting a file on the Mac propagates correctly to the server.
• Only the direction “server-side deletion → removal of the local File Provider item” fails.
• Disabling Keep Downloaded does not resolve the problem.
• The issue is reproducible even with isDownloaded = 0, so it does not depend on content materialization.
• The file is confirmed to be absent from the server.
• notify_push delivers the server-side change to the Mac.

Impact

On systems with multiple computers, the stale item can present an incorrect view of the shared folder state. It may also create a risk of conflicts or re-uploading the item from another computer.

Related issues

• File provider extension does not propagate remote folder deletion #9553 — File provider extension does not propagate remote folder deletion
• [Bug]: macOS File Provider keeps stale folder metadata after successful remote change fetch; unchanged change token with moreComing=true #10556 — macOS File Provider keeps stale folder metadata
• New items from other devices do not appear #10070 — New items from other devices do not appear
• Correct Remote Change Propagation to File Provider Framework #10252 — Correct Remote Change Propagation to File Provider Framework

Questions for the developers

Could this be a regression of #9553 or an uncovered path in the remote-change propagation mechanism addressed by #10252?

Is a corresponding fix planned for 34.0.3?

[BangyStudios]

Yes, can confirm this issue definitely still exists for me (not resolved in #9553). I don't think classic sync should have been removed while there are such significant bugs with virtual file provider.