dropbox: received shared-file names bypass standard encoding conversion #9707

Summary

Received shared-file listings store the Dropbox API's raw Name as the object's rclone remote name. Shared-folder listings convert the corresponding API name with ToStandardName, so the two adjacent shared-mode paths use different filename-encoding contracts.

This is source-proven from the current implementation; I have not reproduced it against a live Dropbox remote with an affected filename.

Evidence

• backend/dropbox/dropbox.go:932-935: listSharedFolders converts entry.Name with f.opt.Enc.ToStandardName.
• backend/dropbox/dropbox.go:1010-1016: listReceivedFiles assigns entry.Name directly to Object.remote without applying ToStandardName.
• backend/dropbox/dropbox.go:1033-1047: findSharedFile compares that raw stored name directly with the requested rclone name.
• Normal rclone-visible remote names are expected to be in the standard-name representation rather than the backend API's encoded representation.

Impact

The impact has not been measured against a live remote. Received shared files whose names require Dropbox encoding conversion may be listed under an inconsistent name or fail direct lookup using their expected rclone-visible name.

Question

Should listReceivedFiles apply f.opt.Enc.ToStandardName(entry.Name) before storing and comparing the object's remote name?

I checked all relevant issues, comments, pull requests, and forum threads; this report is not a duplicate.

Involvement

I am reporting this finding only and am not currently proposing a pull request.

Investigated extensively with GPT-5.6 Sol (xhigh reasoning effort), using Oh My Pi as the agent framework.