You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
Setting client_modified on upload not working
Because of some additional logic we are performing client side, we need to set the client_modified time on an upload. Here is my argument I'm passing on 2/files/upload:
0x08c349f0 "Dropbox-API-...
- Thanks for confirming that. If the file contents are identical, this is the expected behavior. There isn't a great workaround, but we'll consider it a feature request for a way to do this.
Deleting the file first would work, but that may be prone to race conditions, so I'd exercise caution with that.
Also, I'm not sure if this makes sense for your use case, but alternatively you could check the existing content_hash before uploading and not upload anything if it already matches the local copy.
Thanks for the reply. Yes, I blundered on the access token, I meant to remove it from the post, and didn't. I've revoked the app permission and will get a new one.
Yes, the file is identical. I just happen to have two machines I'm testing on, and there is about a 10 second difference in their clocks. So the slightly faster one is trying to update the file, but because it is identical, it doesn't update the metadata. So on every sync, it tries to update again.
So, should I do a 'delete', then an upload to force an update of the metadata?
My other option is to increase the tolerance on the time differential--it's currently at 2 seconds. It's hard to predict what may happen out there in the wild on users' machines. I don't know if you might have a more educated guess.
Thanks again for the reply.
Greg-DB
Dropbox Staff
Dropbox StaffThanks for confirming that. If the file contents are identical, this is the expected behavior. There isn't a great workaround, but we'll consider it a feature request for a way to do this.
Deleting the file first would work, but that may be prone to race conditions, so I'd exercise caution with that.
Also, I'm not sure if this makes sense for your use case, but alternatively you could check the existing content_hash before uploading and not upload anything if it already matches the local copy.
Deleting the file first would work, but that may be prone to race conditions, so I'd exercise caution with that.
Also, I'm not sure if this makes sense for your use case, but alternatively you could check the existing content_hash before uploading and not upload anything if it already matches the local copy.
Thanks, then I know I'm not crazy. :slight_smile:
On your content hash idea, is there a way I can compute that content hash to compute the content hash on the client side that would match what I get back from Dropbox?
I'm just trying to determine if my client file is newer (and different) from the Dropbox file. I'm not sure how I can get that hash if my client file changed. Storing the last upload hash wouldn't help me much--I'd need to run the hash on the (potentially) revised client file.
My only other alternative, I think, is for me to add code client side to use server_modified I get back from an upload and revise the client file's time to server_modified (as well as the timestamp of the last sync we track separately). That would abandon use of client_modified altogether and provide a consistent base for all machines to compare against. In theory, the client file could've gotten modified in that brief interim and changing the date / time stamp would lose that change.
Of course, if things got changed on your end, such that an upload, if it has a client_modified parameter different than the stored client_modified metadata, so that it would at least update the client_modified metadata (if the file is otherwise identical), that would be swell. It is, after a fashion, a modification of the file.
I'll ponder this a bit, but if you have any suggestions, I'd welcome them.
Update, just found:
https://www.dropbox.com/developers/reference/content-hash
so I'll start in on that, so feel free to ignore that part of my reply.
- Greg-DB
I'm glad to see you found the reference page. (Apologies, I should have linked to it in my last reply.)
It sounds like hashing the local file and comparing it will help in your case then, and would be better than just relying on timestamps, as those can differe across machines.
You may also want to check out how you can use 'rev' and the 'update' WriteMode to avoid accidentally overwriting new versions of files:
https://www.dropbox.com/developers/documentation/http/documentation#files-upload
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
