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: 

Re: 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

 

11 Replies 11

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.

Keith B.7
Helpful | Level 7
Go to solution

That seems to fix it, thanks! I tested with my sample app several times and everything is returned in the expected order now, whereas before it was consistently wrong.

Need more support?