cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Want to learn some quick and useful tips to make your day easier? Check out how Calvin uses Replay to get feedback from other teams at Dropbox here.

Dropbox API Support & Feedback

Find help with the Dropbox API from other developers.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Meta-data unreliable in DBFILESUploadSessionFinishBatchResultEntry?

Meta-data unreliable in DBFILESUploadSessionFinishBatchResultEntry?

Keith B.7
Helpful | Level 7
Go to solution

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

 

1 Accepted Solution

Accepted Solutions

Greg-DB
Dropbox Staff
Go to solution
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.

View solution in original post

11 Replies 11

Keith B.7
Helpful | Level 7
Go to solution

Actually, I've found the problem. I was relying on the advice given here:

 

https://www.dropboxforum.com/t5/API-support/uploadSessionFinishBatchCheck-Getting-path-from-errors/m...

 

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
Go to solution
Thanks for the report! We're looking into it.

Greg-DB
Dropbox Staff
Go to solution
Hi 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-DB
Dropbox Staff
Go to solution
Actually, 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.

Keith B.7
Helpful | Level 7
Go to solution

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

Greg-DB
Dropbox Staff
Go to solution

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!

Keith B.7
Helpful | Level 7
Go to solution

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

Greg-DB
Dropbox Staff
Go to solution
Thanks Keith. It was a server-side fix, so we'll keep investigating. And thanks for the sample project! I'll try that out.

Greg-DB
Dropbox Staff
Go to solution
Quick update, it turns out the fix actually wasn't deployed yet. (My apologies!)

I was able to use your sample code to reproduce the issue though, so I'll try it again once the fix is actually deployed to see if that resolves it. That should be later today or tomorrow. I'll follow up here once that's done.
Need more support?
Who's talking

Top contributors to this post

  • User avatar
    Keith B.7 Helpful | Level 7
  • User avatar
    Greg-DB Dropbox Staff
What do Dropbox user levels mean?