Your workflow is unique 👨‍💻 -  tell us how you use Dropbox here.

Forum Discussion

AEmery's avatar
AEmery
Explorer | Level 3
8 years ago

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...
API
Greg-DB's avatar
Greg-DB
Icon for Dropbox Community Moderator rankDropbox Community Moderator
7 years ago

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's avatar
dst
Explorer | Level 3
7 years ago

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's avatar
    Greg-DB
    Icon for Dropbox Community Moderator rankDropbox Community Moderator
    7 years ago
    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's avatar
      dst
      Explorer | Level 3
      7 years ago

      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's avatar
        Greg-DB
        Icon for Dropbox Community Moderator rankDropbox Community Moderator
        7 years ago
        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.

About Dropbox API Support and Feedback

Node avatar for Dropbox API Support and Feedback
Get help with the Dropbox API from fellow developers and experts.

The Dropbox Community team is active from Monday to Friday. We try to respond to you as soon as we can, usually within 2 hours.

If you need more help you can view your support options (expected response time for an email or ticket is 24 hours), or contact us on X, Facebook or Instagram.

For more info on available support options for your Dropbox plan, see this article.

If you found the answer to your question in this Community thread, please 'like' the post to say thanks and to let us know it was useful!