cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Want to learn some quick and useful tips to make your day easier? Check out how Calvin uses Replay to get feedback from other teams at Dropbox 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: 

Handling File Rename/Move in the API [filesListFolderContinue]

Handling File Rename/Move in the API [filesListFolderContinue]

manishrc
Explorer | Level 4
Go to solution

Hello,

 

I'm trying to build a blogging platform powered by markdown files in dropbox.

So, I need to keep the file and the blog in sync.

 

To do this, I am using filesListFolderContinue (JS SDK) and pass the cursor from the previous sync to get the diff.

 

One issue I see is that on a slow/flaky connection or when large files are renamed or moved, dropbox API responds with a delete only as opposed to a delete and a new file.

 

Example below:

[1] When I rename the file original-file.txt to new-file.txt, the response from filesListFolderContinue is:

{
  entries: [
    {
      '.tag': 'deleted',
      name: 'original-file.txt',
      path_lower: '/test/original-file.txt',
      path_display: '/test/original-file.txt'
    }
  ],
  cursor: '...',
  has_more: false
}

 

[2] Just a few seconds later, the response includes the new file is includes, using the same cursor:

{
  entries: [
    {
      '.tag': 'deleted',
      name: 'original-file.txt',
      path_lower: '/test/original-file.txt',
      path_display: '/test/original-file.txt'
    },
    {
      '.tag': 'file',
      name: 'new-file.txt',
      path_lower: '/test/new-file.txt',
      path_display: '/test/new-file.txt',
      ...
    }
  ],
  cursor: '...',
  has_more: false
}

 

I expected to only see the second response, without ever being able to see the first, as there is no way to differentiate an actual Delete vs a Move or a Rename.

 

I would appreciate any recommendations to handle this scenario and differentiate a DELETE VS MOVE/RENAME.

 

Thank you

1 Accepted Solution

Accepted Solutions

Greg-DB
Dropbox Staff
Go to solution

I'm currently using the id field to track move/renames. But the problem was basically that I am unable to differentiate a DELETE from a MOVE. It's not a big problem if some of the actions are idempotent, but unfortunately, they are.

Does dropbox have any plans to fix this behavior and allow the ability to differentiate between a DELETE and a MOVE?

No, I'm not aware of plans to change how this works. If this case is common for your app and it's more effective for your app to process these filesListFolder entries together, you could consider adding a small delay after receiving a 'deleted' entry to catch the potential following additions.

 

You can also use filesListFolderLongpoll to get low-latency monitoring for changes.

Does this avoid the previous problem?

No, this doesn't avoid the issue, but I mentioned it as it may make things faster in your app since it's a way to quickly detect changes. E.g., if you query and get just the deletion, the longpoll would let you know about any further changes, such as an addition, as soon as possible.

 

Also, is there a reason why the id is not included in the deleted files?


This is due to how the Dropbox filesystem is implemented. The 'deleted' entry just indicates that something used to exist at that path, but does not itself have the id of that item (or item(s)) that used to be there.

View solution in original post

4 Replies 4

Greg-DB
Dropbox Staff
Go to solution

There can be a slight delay between new entries like this, as you found. The deletion and addition of a file for a rename or move operation aren't guaranteed to be delivered together, so if you happen to call at the right time you might see the deletion without the addition. If you later call back again to filesListFolderContinue using that returned cursor, you should then see the addition though, so once you process all of the entries the result should be the same.

 

You can also use filesListFolderLongpoll to get low-latency monitoring for changes.

 

Also, note that you can track the Metadata.id for the original file and then the addition of the file at the new path to keep track of files across moves/renames, since the file ID won't change for moves/renames.

manishrc
Explorer | Level 4
Go to solution

Hi Greg,

 

Thank you for your quick reply.

 

I'm currently using the id field to track move/renames. But the problem was basically that I am unable to differentiate a DELETE from a MOVE. It's not a big problem if some of the actions are idempotent, but unfortunately, they are.

 

Does dropbox have any plans to fix this behavior and allow the ability to differentiate between a DELETE and a MOVE?

 

You can also use filesListFolderLongpoll to get low-latency monitoring for changes.

Does this avoid the previous problem?

 

Also, is there a reason why the id is not included in the deleted files?

Greg-DB
Dropbox Staff
Go to solution

I'm currently using the id field to track move/renames. But the problem was basically that I am unable to differentiate a DELETE from a MOVE. It's not a big problem if some of the actions are idempotent, but unfortunately, they are.

Does dropbox have any plans to fix this behavior and allow the ability to differentiate between a DELETE and a MOVE?

No, I'm not aware of plans to change how this works. If this case is common for your app and it's more effective for your app to process these filesListFolder entries together, you could consider adding a small delay after receiving a 'deleted' entry to catch the potential following additions.

 

You can also use filesListFolderLongpoll to get low-latency monitoring for changes.

Does this avoid the previous problem?

No, this doesn't avoid the issue, but I mentioned it as it may make things faster in your app since it's a way to quickly detect changes. E.g., if you query and get just the deletion, the longpoll would let you know about any further changes, such as an addition, as soon as possible.

 

Also, is there a reason why the id is not included in the deleted files?


This is due to how the Dropbox filesystem is implemented. The 'deleted' entry just indicates that something used to exist at that path, but does not itself have the id of that item (or item(s)) that used to be there.

manishrc
Explorer | Level 4
Go to solution
Thank you for your help.
Need more support?
Who's talking

Top contributors to this post

  • User avatar
    manishrc Explorer | Level 4
  • User avatar
    Greg-DB Dropbox Staff
What do Dropbox user levels mean?