Need to see if your shared folder is taking up space on your dropbox 👨💻? Find out how to check here.
Forum Discussion
Solved
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, 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.
Greg-DB
Dropbox Community Moderator
Dropbox Community ModeratorI'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.
