Keith B.7 Collaborator | Level 9

Hi Greg, Thanks for the reply. Unfortunately I am already calling 'recursive=true'. A long shot, but are there any techniques or tricks that can speed up the recursion? Thanks and all the best, Keith

That was fast! I can confirm that it's fixed - many thanks!

Great, thanks.

Thank you. Does the error only ever apply to downloads, then? Will this error never be encountered for uploads, or when trying to copy or move a restricted file? Thanks, Keith

There's a decent example of using the Dropbox API to sync a folder between the local device and the server here: https://github.com/chrishulbert/CHDropboxSync/blob/master/CHDropboxSync.m It's written in Objective-C and uses the Core API (API 1), but the basic logic is good. You'd need to translate it to your language and…

It all builds fine now - thanks for the quick resolution! All the best, Keith

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.

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…

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…

Unfortunately, it turns out the order doesn't match after all, as explained here: https://www.dropboxforum.com/t5/API-support/Meta-data-unreliable-in/m-p/192288/highlight/false#M8529 I've therefore returned to my previous method. Thanks and all the best, Keith

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-p/191846#M8441 Based on the assumption that the [(DBFILESUploadSessionFinishBatchJobStatus * )status complete].entries.array will be in the same…

Great, thanks. Following your advice, I've got checking for revoked access and re-linking all working - much appreciated! All the best, Keith

Great, thanks for the clarification. So, instead of an equivalent of DBSession's -sessionDidReceiveAuthorizationFailure: delegate method, I check for DBError's -isAuthFailure in the response of any of the Dropbox requests? That makes sense, thanks!

Hi Greg, Thanks for the answer. That's a good idea - following our discussion about cancelling all tasks, I created a "Dropbox task manager" class that I use to invoke all the -response: and -progress: methods for tasks passed into it so that it can keep an array of all running tasks. So I've placed the notifications in…

Great, thank you!

Thanks for retrieving my post! Thanks for the reply, too. I realised that one way I could get a list of the failures was by checking a cached list of what was currently being uploaded against the meta-data for successful uploaded files - everything else being a failure. Using the index is even better, though: so is it…

Great, thank you. Okay, so from your answer, I've tracked through the various classes again and mostly got there. So: 1. Once -uploadSessionBatchFinish: completes, its response callback gives you aDBASYNCLaunchEmptyResult object. 2. You can use the .asyncJobId of that empty result object to invoke…

Ah, okay, makes sense. I was thinking that the chunks were being stored against the user's Dropbox quota so would throw the error too. Thanks, Keith

Actually, a quick question on the NSFileHandle example regarding this part: func uploadNextChunk() { data = fileHandle!.readDataOfLength(chunkSize) let size = data!.length print("Have \(size) bytes to upload.") if size < chunkSize { print("Last chunk!") Dropbox.authorizedClient!.files.uploadSessionFinish( Why is this line:…

Great, thanks. It might be an idea to put a note about this in the documentation, as it's not at all clear that the URL should point to a single chunk of data, especially as it's done differently from API 1 (I'm not even sure how you would have a URL point to a chunk of data). I've moved over to using NSFileHandle, though,…

I'm trying to get this to work right now, but one thing I cannot figure out is how to calculate the offset. I can't quite work it out from the Swift code - it seems that there's a set chunk size there of 5MB, but I don't know why that is. And I'm using the -uploadUrl: method rather than the -uploadData: methods that are…

Great, thanks again! All the best, Keith

Great, thanks!

Okay, thanks - I'll just grab it directly from the info.plist file, then. All the best, Keith

In your example, you would get it like this: self.dropboxFileRevision = ([result isKindOfClass:[DBFILESFileMetadata class]] ? [(DBFILESFileMetadata *)result rev] : nil); DBFILESFileMetadata is a subclass of DBFILESMetadata. Basically (as I understand it), you’ll never receive a vanilla DBFILESMetadata object in a response,…

Great, thank you.

Thanks. I think there's a minor documentation mistake in the DBFILESWriteMode.h file that is what makes this unclear. For -initWithUpdate:, it says this: /// @param update Overwrite if the given "rev" matches the existing file's /// "rev". The autorename strategy is to append the string "conflicted copy" to /// the file…

Hmm, actually, looking more at DBFILESWriteMode, is the rev what you are supposed to pass into -initWithUpdate:? So, e.g.: NSString *rev = ... // rev cached from a previous upload or listFolder: result. DBFILESWriteMode *update = [[DBFILESWriteMode alloc] initWithUpdate:rev]; DBUploadTask *uploadTask =…

Hmm, revisiting the code, it seems I mainly used the modification dates against folders for consistency with the way files were cached. The problem is less that they are needed for any comparison and more that the cached database file saves folder names against the dates. I should just be able to use any date for folders…

Ouch. My whole caching method relies on storing a date against every file and folder. That's a bit of a blow for a smooth transition...