Your workflow is unique 👨💻 - tell us how you use Dropbox here.
Forum Discussion
Renamed shared folder reported both as new and deleted by /list_folder/continue
Hello Greg,
Found a strange behavior with /list_folder/continue that you might be able to clarify. Here's how to reproduce:
- Using /list_folder/continue until you get the last cursor.
- Re...
Good point, I did not think about this name having ever been used. So, to be sure I did the same test again with both old and new names being random strings that surely has never been used in the whole account. I get the same behavior.
The processing order is hard to enforce when working in a threaded context so having both a new and a deleted folder might result in an unpredictable behavior.
Anyway, thank you for the quick feedback and I'll be happy to help if you need more context to be able to replicate this behavior.
Greg-DB
Dropbox Community Moderator
Dropbox Community ModeratorThanks! We'll look into it.
Note that is is important that your app process these entries in order. Otherwise, you may not get a state consistent with the state on the Dropbox servers.
Note that is is important that your app process these entries in order. Otherwise, you may not get a state consistent with the state on the Dropbox servers.
Hi Greg K.
We got tha same issue when trying to sharing folder.
Reproduce steps:
1. create a test_folder and add sub-folder a, b, c, d, e
2. sharing test_folder/a, test_folder/b, test_folder/c, test_folder/d, test_folder/e
3. /list_folder/continue will report folder delete event and folder sharing event
---------------------------------------------------------------------------------------------------------------------------------
{
"entries":[
{
".tag":"deleted",
"name":"d",
"path_lower":"/test_folder/xx/d",
"path_display":"/test_folder/xx/d"
},
{
".tag":"deleted",
"name":"b",
"path_lower":"/test_folder/xx/b",
"path_display":"/test_folder/xx/b"
},
{
".tag":"folder",
"name":"b",
"path_lower":"/test_folder/xx/b",
"path_display":"/test_folder/xx/b",
"id":"id:8hk3XBzqwAoAAAAAAAMtfQ",
"shared_folder_id":"2218134592",
"sharing_info":{
"read_only":false,
"shared_folder_id":"2218134592",
"traverse_only":false,
"no_access":false
}
},
{
".tag":"folder",
"name":"d",
"path_lower":"/test_folder/xx/d",
"path_display":"/test_folder/xx/d",
"id":"id:8hk3XBzqwAoAAAAAAAMtfw",
"shared_folder_id":"2218136512",
"sharing_info":{
"read_only":false,
"shared_folder_id":"2218136512",
"traverse_only":false,
"no_access":false
}
}
],
"cursor":"xxx",
"has_more":true
}
---------------------------------------------------------------------------------------------------------------------------------------- Greg-DB
dst Based on the output you shared, this doesn't appear to be exactly the same as the issue originally reported on this thread. I.e., the original issue reported having duplicate entries, but I don't see any duplicate entries in your output.
Seeing the separate deletion and addition (one each per 'b' and 'd' in your output) is expected. Just make sure you process these in order as documented so you can get the correct state.
Hi Greg K.
Thanks for your reply. I can descript our scenario more precisely.
When sharing a folder "/list_folder/continue" API will response a folder's delete and then a folder's create event.
We can make sure our application process these event in sequence but it will lead we have to re-synchorization the folder again when sharing a folder.
For example,
We have a folder "/Folder" with some files "/Folder/file1", "/Folder/file2"
When sharing "/Folder", list_folder API will report "/Folder" a delete and a create event
we will remove /Folder entirely by "/Folder" delete evnet
and then re-create /Folder by create event and re-download "/Folder/file1", "/Folder/file2".
The sync state will be correct finally but the files have to re-download is not a friendly design for user.
Is there any chance to enhance the API's behavior to avoid application have to re-download the files after sharing a folder?
About Dropbox API Support and Feedback
Get help with the Dropbox API from fellow developers and experts.
