We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
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)...
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.
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
Dropbox Staff
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.
- Thank you for your help.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
