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-Arg: {"path":"/Highlights/My Highlights.hlt","client_modified":"2017-3-29T20:34:36Z","mode":{".tag":"overwrite"}}"
Note the 36Z.
and I get a 200 response, but looking at the response data:
+ response 0x10d90060 "{"name": "My Highlights.hlt", "path_lower": "/highlights/my highlights.hlt", "path_display": "/Highlights/My Highlights.hlt", "id": "id:6_dWokRAKIYAAAAAAAAAqg", "client_modified": "2017-03-29T20:34:26Z", "server_modified": "2017-03-29T20:34:26Z", "rev": "4591aae215f", "size": 1820, "content_hash": "c94fdea96874357d0695095be2627735033ff3ef8e6efd5d2d450b07ac2fa368"}" char *
it appears my 36Z has morphed into 26Z, which matches server_modified.
So my questions are:
1. Does setting client_modified on the upload work? (I also need to use it on upload_session/finish.)
2. Have I blundered in the argument I'm passing? (That was my first assumption, thinking that I wouldn't get a 200 and the response would contain an error message describing my blunder.)
I know server_modified is recommended, but again, we do some additional sync processing on the client side that forces me to set and use client_modified.
Thanks for any help on this.
- 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.
A bit more detail. I used the Dropbox API Explorer. Here is the 'Code" (bearer token eliminated):
curl -X POST https://content.dropboxapi.com/2/files/upload \ --header 'Authorization: Bearer <ACCESS_TOKEN>' \ --header 'Content-Type: application/octet-stream' \ --header 'Dropbox-API-Arg: {"path":"/Highlights/My Highlights.hlt","mode":{".tag":"overwrite"},"client_modified":"2017-03-29T20:34:26Z"}' \ --data-binary @'My Highlights.hlt'and here is the Response:
{ "name": "My Highlights.hlt", "path_lower": "/highlights/my highlights.hlt", "path_display": "/Highlights/My Highlights.hlt", "id": "id:6_dWokRAKIYAAAAAAAAAqg", "client_modified": "2017-03-29T20:34:26Z", "server_modified": "2017-03-31T17:17:43Z", "rev": "4721aae215f", "size": 0, "content_hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" }where one will note the maddening conversion to :26Z from 36Z.
And I don't pretend to understand why in this case, the server_modified is changing, but in the prior post's response, the server_modified matched the client_modified (albeit at 26Z). That prior post was run today as well.
- Greg-DB
Dropbox Staff
The client_modified functionality is working properly for me right now. Are you uploading the same exact file data each time by any chance? If you do, that's not considered a change, so the metadata won't get updated.
Also, it looks like you did originally post an access token on another reply here, so for the sake of security, you should disable that access token, since it was public and possible emailed in forum notifications. You can do so by revoking access to the app entirely, if the access token is for your account, here:
https://www.dropbox.com/account/security
Or, you can disable just this access token using the API:
https://www.dropbox.com/developers/documentation/http/documentation#auth-token-revoke
(By the way, it looks like we did have an issue with the forum where your post didn't appear. We fixed that, so I just deleted the extra one.)
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.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
