Child Item

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.

- Rename a shared folder (here "OldName" to "NewName")

- Calling /list_folder/continue with the last cursor gives me this:

{
"entries": [
{
".tag": "deleted",
"name": "oldname",
"path_lower": "/oldname",
"path_display": "/oldname"
},
{
".tag": "deleted",
"name": "newname",
"path_lower": "/newname",
"path_display": "/newname"
},
{
".tag": "deleted",
"name": "OldName",
"path_lower": "/oldname",
"path_display": "/OldName"
},
{
".tag": "folder",
"name": "NewName",
"path_lower": "/newname",
"path_display": "/NewName",
"id": "id:FolderId",
"shared_folder_id": "1479396978",
"sharing_info": {
"read_only": false,
"shared_folder_id": "sharedFolderId"
}
}
],
"cursor": "someCursor",
"has_more": true
}

Two things looks strange to me here. I get the OldName twice: with and without casing. This I can manage, but the Folder "NewName" being returned both as deleted and as a new folder is more of a problem. Is it an expected behavior?

Also, this is a behavior that I can reproduce using APIv1 /delta with a cursor. Renaming a simple (not shared) folder returns simply one entry for the deleted OldName and one for the NewName as I was expecting.

Thank you for your help.

Find more posts tagged with

API

Abuse

Comments

Greg-DB

Thanks for the report! I'm seeing the duplicate "/oldname" in my testing, but not the extra deleted "/newname", though I expect it will depend on the particular state of the account. In this sample, did you previously have anything at "/newname" by any chance?

We'll look into whether or not we can clean this up, but the entries as shown here should still give you the correct state as long as you process them in order according to the rules indicated in the /files/list_folder documentation:

https://www.dropbox.com/developers/documentation/http/documentation#files-list_folder

I.e., Per "If there's nothing at the given path, ignore this entry.", you should make sure your app is able to ignore any such entries, such as these redundant deleted ones.

AEmery

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

Thanks! 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.

dst

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.

dst

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?

Greg-DB

It's unlikely that the list_folder behavior will change, but you can avoid re-downloading file data by storing and checking the FileMetadata.content_hash for the file data you have saved locally, and comparing it to the new entry. If the content_hash is the same, the data hasn't changed.

dst

Hi Greg K.,

The main issue will be folder delete event. If we process the event comes from server in sequence, we will remove the folder first and then re-create it when sharing a folder.

so we have to merge delete and sharing folder by ourself when using "/list_folder/continue" or is there any suggestion to deal with issue?

Greg-DB

The exact behavior of your app is up to you, but yes, you may wish to correlate the events and check the content_hash values in order to avoid removing all of the data.