Surface files that failed to upload, and uploads the OS has given up retrying

[weiaoli2]

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

Feature request

Which Nextcloud Version are you currently using: Desktop client 34.0.1 on macOS 15.7 (File Provider / virtual files enabled)

Is your feature request related to a problem? Please describe.

There is currently no way to see, from the client, that a file has failed to upload — or that macOS has stopped trying.

With the File Provider backend, failed operations are throttled with an exponential backoff and eventually reach next: 'never': the daemon has permanently given up and will not retry on its own. Nothing in the UI reflects this. The folder still looks complete, and every file still reports its full size to Finder, ls and any backup tool, whether or not its contents exist locally.

That produces a state I think is worth naming explicitly: a file that exists only on the user's Mac, inside a folder they believe is backed up. A placeholder is safe (the server has it) and a synced file is safe (both have it), but a failed upload is a single copy, and it is indistinguishable from the other two in the interface.

This is not hypothetical. In #10513, users on 34.0.0 saw a green checkmark while nothing transferred in either direction. Several lost days before realising, and the diagnosis only came when somebody read the client logs and found 0 folder(s) migrated and Folders to sync: 0 while the UI still showed success. (That specific regression appears fixed in 34.0.1 — my point is about the visibility gap it exposed, which outlives the bug.)

Describe the solution you'd like

A view in the client — a "Not synced" list, or a section in the existing activity window — showing:

• files that exist locally but have no server counterpart, with sizes
• items the OS has permanently given up retrying, and when it last tried
• the underlying error, translated (NSFileProviderErrorCannotSynchronize etc.)
• pending deletions queued against the server

Plus a non-green indicator whenever the first category is non-empty. The current model appears to treat "no operations in flight" as success, but an empty queue because everything was abandoned looks identical to an empty queue because everything succeeded.

Describe alternatives you've considered

I wrote a read-only diagnostic to answer this for myself, which is really the argument for the feature: the data is already there. fileproviderctl dump <domain> exposes all of the above — the reconciliation state pairs each local item against its server counterpart, unmatched entries are visible, and the throttling section carries the error code, attempt count and next retry time.

https://github.com/weiaoli2/ncstatus — macOS, Python, MIT, no dependencies. Sample output in the README.

It is a diagnostic, not a proposed implementation: Python and macOS-only, where the client is C++/Qt and cross-platform. I am not suggesting it be adopted. It only demonstrates that a client-side view of this would not require new plumbing on the server or a protocol change — the OS already knows, it just is not asked.

Two implementation notes that cost me time and might save someone else's:

• Resolving an item's parent fileID by walking the sync folder is a trap. Every directory listing makes the daemon fetch metadata from the server; on a freshly re-registered domain that took 6m38s. /.vol/<device>/<inode> with the F_GETPATH fcntl answers the same question in O(1) with no server traffic — the same report then took 2.5s.
• Reading a placeholder's contents materialises it, so anything that inspects the tree has to work from metadata only, or it silently downloads the user's whole account.

Additional context

The mechanism above is macOS-specific, but the user-facing problem is not: any virtual-files backend can end up with a local-only file and no way for the user to notice. If a similar view is feasible on Windows via CFAPI, the same reasoning applies there.