Client: 34.0.2.0 (macOS build)
Server: Nextcloud 34.0.3 (self-hosted)
OS: macOS 26.6.2 (25G83)
A folder that was deleted server-side (confirmed gone both on the server and locally — nothing to sync) is stuck as a permanent sync error via the macOS File Provider integration. FileProviderExt's log shows a DELETE request for the folder and each of its former subfolders repeating indefinitely, every one returning 404 Not Found from the server (expected, since the item is already gone) — but the client never clears the pending operation, so it retries on every enumeration cycle indefinitely. This produces a persistent "some files couldn't be synced" state in Activity with no itemized error listed underneath it (a second, separate bug — the error simply isn't surfaced there since it lives in the File Provider domain, not the classic sync engine).
Previously this was recoverable by toggling virtual-files support off/on for the account to force a File Provider domain rebuild. That setting appears to have been removed in 34.0.2, leaving no user-facing way to reset the domain short of fully removing and re-adding the account.
Requests:
- Treat a
404 on a pending DELETE operation as success (item already gone) and clear it, instead of retrying forever.
- Surface File-Provider-domain-level errors in the Activity error list, not just classic sync-engine errors.
- Restore (or provide an alternative to) a way to reset/rebuild a File Provider domain without removing the whole account.
Client: 34.0.2.0 (macOS build)
Server: Nextcloud 34.0.3 (self-hosted)
OS: macOS 26.6.2 (25G83)
A folder that was deleted server-side (confirmed gone both on the server and locally — nothing to sync) is stuck as a permanent sync error via the macOS File Provider integration.
FileProviderExt's log shows aDELETErequest for the folder and each of its former subfolders repeating indefinitely, every one returning404 Not Foundfrom the server (expected, since the item is already gone) — but the client never clears the pending operation, so it retries on every enumeration cycle indefinitely. This produces a persistent "some files couldn't be synced" state in Activity with no itemized error listed underneath it (a second, separate bug — the error simply isn't surfaced there since it lives in the File Provider domain, not the classic sync engine).Previously this was recoverable by toggling virtual-files support off/on for the account to force a File Provider domain rebuild. That setting appears to have been removed in 34.0.2, leaving no user-facing way to reset the domain short of fully removing and re-adding the account.
Requests:
404on a pendingDELETEoperation as success (item already gone) and clear it, instead of retrying forever.