cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
What’s new: end-to-end encryption, Replay and Dash updates. Find out more about these updates, new features and more here.

Dropbox API Support & Feedback

Find help with the Dropbox API from other developers.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Re: Move API leads to temp permission removed for team subfolders/subfiles (eg. 5 to 30s observed)

Move API leads to temp permission removed for team subfolders/subfiles (eg. 5 to 30s observed)

ethanfang
Explorer | Level 4
Go to solution

Hi,

We've developed an syncing app, and we found that if we use move api (eg. https://api.dropboxapi.com/2/files/move_v2) with Dropbox-API-Path-Root as root teamspace id to rename team folder under team space root.

The subfolders and subfiles of the renamed team folder will then lose their permissions (eg. the members can't access those subfolders or subfiles at the temporary period) for around 5 to 30 seconds.
Moreover, the response message is no_write_permission, which is the same as the response for those without permissions who want to access files will receive.
{

    "error_summary""path/no_write_permission/..",
    "error": {
        ".tag""path",
        "path": {
            ".tag""no_write_permission"
        }
    }
}

We can't distinguish if it's a temporary permission lose or it is just simply no permissions by api response. And we don't want to send another api to poll for 5 to 30 seconds every time we met an no permission issue.
Could you please help to resolve the temporary permission lost issue, or provide us a way to distinguish the "tempororary" permission lost from "no" permission cases with the api response?

Thank you~!
Best regards,

Ethan Fang

1 Accepted Solution

Accepted Solutions

Greg-DB
Dropbox Staff
Go to solution

Thanks for sharing this. As you found, the Dropbox back-end needs to perform some additional work immediately after an operation like this. There isn't a way to check on or disambiguate this programmatically unfortunately, so please add a sufficient delay/retry. I know this is non-ideal and can be slow, so I'll send this along as feedback to the team to see if we can improve or eliminate this in the future. Apologies for the bother.

View solution in original post

1 Reply 1

Greg-DB
Dropbox Staff
Go to solution

Thanks for sharing this. As you found, the Dropbox back-end needs to perform some additional work immediately after an operation like this. There isn't a way to check on or disambiguate this programmatically unfortunately, so please add a sufficient delay/retry. I know this is non-ideal and can be slow, so I'll send this along as feedback to the team to see if we can improve or eliminate this in the future. Apologies for the bother.

Need more support?