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.
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
Dropbox StaffThe 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.
- Greg-DBThanks 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, 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.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
