Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
Hello,
I'm using chunked uploads to upload files (although this may affect regular uploads, too - I haven't checked that yet). I use the clientDate parameter of DBFILESCommitInfo to ensure the displayed date on Dropbox matches the displayed date in the local file system (a very welcome addition to API 2, thanks!), so that it is the same across systems. (i.e. By grabbing the modified date of the local file via NSFileManager and passing it into DBFILESCommitInfo).
Because I'm the paranoid sort, and because I use dates to perform various checks, whenever an upload has completed, I check the final client date on the server and update the local file to match if necessary - I do this just as a failsafe, in case the date I have asked Dropbox to apply in DBFILESCommitInfo isn't respected for any reason.
The problem, however, is that the client date of the DBFILESFileMetadata is unreliable (i.e. often incorrect) in DBFILESUploadSessionFinishBatchResultEntry. So, if I grab the clientModified date from the -success meta-data object of such an entry once -uploadSessionFinishBatchCheck: returns a result, it is frequently wrong - it is neither the date I asked to be applied nor the same as the serverModified date.
The next time I call -listFolderContinue:, the -clientModified date of the same file is now correct - that is, the date I expected to be applied to it in the first place, the one I specified in DBFILESCommitInfo. But this is too late, because I'm checking the date in -uploadSessionFinishBatchCheck: and updating the local file based on that, meaning that I'm assigning the wrong date.
At the moment, it seems the only workaround for this problem is either to rely on Dropbox assigning the client date at some point later (as it seems to), or to call -listFolder again after I've finished uploading everything. I don't like the former because I prefer being absolutely sure the dates match, and the latter adds another step, slowing things down.
I'd be grateul for advice on how I can best ensure the client modified dates of my local files match the server dates after an upload.
Thanks!
Keith
Actually, I've found the problem. I was relying on the advice given here:
Based on the assumption that the [(DBFILESUploadSessionFinishBatchJobStatus * )status complete].entries.array will be in the same order as the finish args passed into -uploadSessionFinishBatch:, I was doing the following:
1. Maintaining an array of custom task objects in the same order as the finish args array to be passed into -uploadSessionFinishBatch:.
2. In the finish check method, I was iterating through the status.complete.entries using a for() loop, and using the index to grab my custom task objects.
3. I was then updating my custom task objects and the file on disk associated with the task object with the date in the meta-data object of DBFILESUploadSessionFinishBatchResultEntry.
Unfortunately, it turns out that the array of entries returnd by -uploadSessionFinishBatchCheck: is *not* in the same order as the array of finish args passed into -uploadSessionFinishBatch: after all. Using the index of the DBFILESUploadSessionFinishBatchResultEntry objects to grab my tasks was therefore resulting in the wrong task, and thus the wrong date was being applied to the file and task object.
All the best,
Keith
Hi Greg,
Great, glad you've found a case! This is actually happening consistently for me, though - I get random results every single time I try. I've created a test project in case it helps. You can download it here:
https://dl.dropboxusercontent.com/u/24954/DBChunkedUploadBug.zip
To use:
1. Build and run in Xcode 8 on macOS 10.12.
2. Tap "Sync" to link Dropbox.
3. Tap "Sync" again to upload a bunch of files. The code will create a "ChunkedUploadsTest" folder at the root of your Dropbox folder, and into that it will upload 26 text files containing "lorem ipsum" text, with file names from A to Z.
The code iterates through the DBFILESUploadSessionFinishBatchResultEntry entries array using a for() loop, and it uses the index to retrieve both the DBFILESUploadSessionFinishBatchResultEntry object from the entries array and a custom task object from another array that is in exactly the same order as the finish args array passed into -uploadSessionFinishBatch:. It looks the file name of both the batch result entry and the custom task object with a divider between them. From this, you can see from the output on the Console that the results do not match - the DBFILESUploadSessionFinishBatchResult entries array is never in the same order as the finish args array passed into -uploadSessionFinishBatch:.
All the relevant Dropbox code can be find in the MasterViewController.m file.
As I say, I have another way of getting the information I need, so this isn't holding me back, but hopefully the sample project will help confirm that the case you have found is the same as what I am experiencing.
All the best,
Keith
Thanks Keith! It's possible that the issue only reliably reproduces on some accounts/files and not others.
We just deployed a fix. Can you try again and let me know if you're still seeing the issue or not? Thanks!
Hi Greg,
Unfortunately, I'm getting exactly the same results as before (using the sample app I sent you). I wasn't sure whether the fix was on the server side or in the Obj-C frameworks, though. So, I first just tried running the sample app, and I got the same results as before - the order of the entries array is entirely random and does not match the finishArgs array.
I then tried re-downloading the Obj-C framework, but unfortunately after re-downloading it wouldn't build for me, constantly telling me that DBTaskStorage.h was missing. (Then, when I swapped back to the older framework that was working before, it built, but with loads of warnings about missing parameters, apparently picking up the @param keywords in the comments of the header frameworks, bizarrely - I'm not sure what I've messed up there!) I'm sure the problems with the framework are something silly I'm doing, but I'm off for a week away in a couple of hours, so I'm afraid I don't have time to look into what's gone wrong before I go.
So, because I'm away for a week (which at least means you get a breather from the barrage of questions 🙂 ), if the fix is in the Obj-C framework, I won't be able to test it until I get back next weekend - sorry about that. If the change was on the server side, though, then I'm afraid it doesn't seem to have fixed anything.
Many thanks,
Keith
Hi there!
If you need more help you can view your support options (expected response time for a ticket is 24 hours), or contact us on X or Facebook.
For more info on available support options for your Dropbox plan, see this article.
If you found the answer to your question in this Community thread, please 'like' the post to say thanks and to let us know it was useful!