[BUG] View Trash: remaining cases (Dropbox tier, OneDrive/pCloud OAuth)

[EhudKirsh]

Describe the bug
Clicking on the red View Trash 🗑 button doesn't work for many cloud drives.
I noticed a difference between when Crypt is On and Off, so here are my observations:

Cloud Drive	With Crypt	Without Crypt
Google Drive	⚠ Failed to access Google Drive provider	Works fine
pCloud Drive	⚠ Failed to access pCloud provider	⚠ Authentication failed: Log in required.
MEGA, using its API with and without MEGAcmd	⚠ Failed to access MEGA provider	Works fine
kDrive	⚠ Failed to access kDrive provider	Works fine
Koofr	⚠ Not a Koofr connection	Works fine
box	⚠ Box downcast failed	Works fine
OpenDrive	⚠ Failed to access OpenDrive provider	Works fine
Jottacloud	⚠ Not a Jottacloud connection	Works fine
OneDrive	Haven't tested	List trash failed: 400 Bad Request: {"error":"code":"invalidRequest","message":"The special folder identifier isn't valid","innerError":{"date":"...
Dropbox	⚠ Dropbox downcast failed	Works fine

These are all checked when using OAuth and API, not WebDAV.
I'm also not mentioning here cloud drives that don’t seem to currently support the red View Trash 🗑 button.

Expected behavior
The red View Trash 🗑 button should always work. If there should be a difference between when Crypt is On or Off, it should be clear to the user,
just like the problems I reported of cd, ls and tree not working with Crypt.

Environment:

• OS: Windows 10
• AeroFTP Version: v4.1.2

Additional context
I don't think I see a difference between the current path and whether its name is encrypted or not,
like cd, which failed when Crypt is On in folders with unencrypted names.

[axpnet]

Fixed on main, shipping in the next release (v4.1.3). Leaving this open for your direct confirmation once you can test that build.

[axpnet]

Thanks for the report @EhudKirsh.

Root cause: the trash, restore and empty commands downcast the live provider straight to the concrete provider type. With a Crypt overlay active that box is a CryptOverlayProvider, so the downcast returned None and every trash operation failed with "Failed to access X provider" / "downcast failed" / "Not a X connection".

Fix: a concrete_provider_mut helper now peels the overlay to the inner transport (a no-op when Crypt is off) before every provider-specific downcast across the trash surface. Trash entry display names are also decoded for the providers whose restore round-trips an opaque token, while the underlying path and metadata stay byte-for-byte raw so restore remains exact.

Landed on main in c2868fb4 and it ships in the next release, v4.1.3.

[EhudKirsh]

The original issue is now fixed with all the cloud drives that I tested, except for Dropbox, OneDrive and pCloud Drive.
The remaining problems are almost certainly due to OAuth bugs now, as all the Crypt issues here seem to have been fixed.

Dropbox

I don’t see a red '🗑 Permanent Delete' button or an orange-brown '⚠ Empty Trash' button.

OneDrive

As I wrote in point 10 in #369 (comment), there’s actually another issue that I have with OneDrive, which might be causing it.
If it’s causing this issue, I might as well report it here instead of opening yet another issue. I don’t seem to be able to sign in to OneDrive, which is now ironic, since I wrote the guide on it in #321. Trying to sign into OneDrive through AeroFTP gives this error in the new browser tab it opens after I enter the email to my personal Microsoft account:

Microsoft | Account
We're unable to complete your request
invalid_request: The provided value for the input parameter 'redirect_uri' is not valid. The expected value is a URI which matches a redirect URI registered for this client application.

In other words, I pretty much only managed to sign into OneDrive one time, and it generated a token that seems to work well.
So I can still browse my OneDrive files in AeroFTP using that token, but not generate a new one. I’m almost certain that this is a bug on AeroFTP’s side, because I just deleted OneDrive’s token from rclone.conf, ran rclone config reconnect OneDrive: and it regenerates a token in rclone.conf and shows its iconic message in the browser tab that opens when OAuth manages to connect:

Success!
All done. Please go back to rclone.

I’m not sure if this bug is new. It might’ve been around for a while now.

pCloud Drive

Unlike with OneDrive, I do manage to sign into pCloud Drive again in AeroFTP, but its problem remains.
Although, something has changed for it: now I no longer see ⚠ Failed to access pCloud provider.
I only see ⚠ Authentication failed: Log in required. This means that you’ve successfully fixed whatever issue there was with Crypt here, and now it’s likely some OAuth problem that remained. I’m not sure if it’s on AeroFTP’s side or pCloud Drive’s side.

---

MEGAcmd API

Also, while on this topic, I encountered a related issue. While MEGAcmd API soft-deletes files, it hard-deletes folders.
When MEGA API soft deletes a folder, and MEGAcmd API tries to delete it, I get this error: Permanent delete failed for try: Server error: [2026-07-17 10-17-34.761824 cmd ERR Unable to delete folder: //bin/try. Use -r to delete a folder recursively]