Setting client_modified on upload not working

[Scott_M]

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. 

[Scott_M]

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]

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.)

[Scott_M]

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 · Accepted solution]

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.

[Scott_M]

Thanks, then I know I'm not crazy.

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.

[Scott_M]

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