Restore (inadvertently) deleted folder associated with Dropbox App

[acschg]

Hello,

I'm seeking help with a recent problem that has arisen with an App (built on the Dropbox .NET SDK, running as a part of cloud-hosted Windows Service, and using a long-lived refresh token for OAuth access) that had been running successfully for a couple of years.

Originally, the App looked for files in its top-level App folder for processing, and - when complete - deleted all such files. Recently, the need has arisen to do a recursive search in sub-folders below the App's top-level folder as well and I was modifying the C# .NET code logic such that it would search for files in the top-level folder, and, additionally, recursively in sub-folders. Then - after having processed all such files - delete these files and any empty folders in the App file/folder tree. My intention is/was to NOT delete to top-level App folder when it was empty, but, due to a coding error, I did programmatically delete (via DeleteV2Async) the top-level folder associated with the App.

And, now, it seems the App is broken. Specifically, I'm seeing a 'path/not-found' error when calling ListFolderAsync on the top-level folder. As a side note, I can still see the folder in the Dropbox web UI for my account. And I've tried (multiple cycles of) restore/delete from the web UI, but still the App is getting that path/not-found error when calling ListFolderAsync on that folder. Also of note, when I call ListFolderAsync on the root path ("") and with includeDeleted = true, I can see the top-level App folder in the resulting Metadata list and its IsDeleted property is true.

I've been searching for a way to programmatically restore the App's top-level folder but, based on what I've found online, folders are not restorable in this way - only files. So I'm stuck: restoring via the web UI doesn't seem to change this folder's deleted status in the .NET App, but there seems to be no way (that I've found) to restore this folder programmatically.

Is there a way to solve this problem?

[Greg-DB · Accepted solution]

The Dropbox API and the Dropbox web site both use the same filesystem data, so it's not expected that you'd see a different state (e.g., deleted or not deleted) for the same item at the same time across the two interfaces. Can you double check you're looking at the same item in both places? For instance, you can call GetCurrentAccountAsync to check which account you're connected to on the API, and use the account drop-down menu in the top right to see which account you're signed in to on the web site.

Keep in mind that app folders are unique to each app-account pair. Different apps in the same account would have different app folders, and the same app connected to multiple accounts would have a separate app folder for each account.

In any case, while you can't restore an entire folder and its contents using the API, you can create a folder at a path using CreateFolderV2Async, and restore any specific desired file (e.g., under that path) using RestoreAsync. And while the Dropbox API doesn't offer an API call to return information about which app folder it's operating in (since apps with the app folder access type aren't supposed to be able to access any information above the root of their app folder), creating a folder would be a good way to test which app folder you're connected to (e.g., when comparing to the web site).

[acschg]

Thanks, @Greg-DB, your suggestions helped me resolve the issue.

Specifically, I discovered that the Dropbox account that was being used at runtime for the App was the "wrong" account in that it was not the account used to create the App. Presumably, this occurred because the API calls to generate an offline refresh token were done from this "wrong" account rather than the intended one.

Having determined and corrected this, then we used the API call to recreate the deleted App folder.

All is functioning correctly now, and I have a better understanding of the relationship between Dropbox accounts and Apps and their associated folders.

Thanks again.