Child Item

Handling File Rename/Move in the API [filesListFolderContinue]

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

Find more posts tagged with

API

Abuse

Accepted answers

Greg-DB

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.

All comments

Greg-DB

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

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

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?

manishrc

Thank you for your help.