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
Meta-data unreliable in DBFILESUploadSessionFinishBatchResultEntry?
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
- Ok, the fix is rolling out now. I just tried the sample code again, and it's no longer reproducing the issue for me.
Please try it out when you get a chance and let me know if you're still seeing the issue.
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- Greg-DB
Dropbox Staff
Thanks for the report! We're looking into it. - Greg-DBHi Keith, I can't seem to reproduce this. Can you share the relevant code snippets and the out of order output you're getting? Thanks in advance!
- Greg-DBActually, we've found a case where this can occur. We're working on it, and I'll follow up here once I have an update for you.
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
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
