Steve M. Dropboxer

Could you tell us which app you were using? The app key would uniquely identify it. (Do not share the app secret, just the app key.)

I think calling https://www.dropbox.com/developers/documentation/http/documentation#sharing-list_shared_links with the path to the file you're interested in and direct_only=true is the best way to do this. In Java, I believe that would be: ListSharedLinksResult result = client.sharing().listSharedLinksBuilder()…

This question seems unrelated to the original question in this thread. Please create a new post to ask a new question.

That depends on which SDK you're using, but the tutorial for that SDK should show you how to do that. E.g. the "Downloading files" section of https://www.dropbox.com/developers-v1/core/start/ios or the "Try some API requests" section of https://www.dropbox.com/developers/documentation/swift#tutorial.

Downloading a file using the Dropbox API will give you the raw bytes of the file. If you want to then convert that to Base64, you'll have to do that yourself. Here's an example I found by searching for "ios base64": http://iosdevelopertips.com/core-services/encode-decode-using-base64.html.

Unfortunately, the Dropbox API doesn't expose OS X extended file attributes, but I'll pass this along to the team as a feature request.

I don't think the API makes any guarantees about the size of these payloads. I believe that in practice I tend to see results sets on the order of thousands of entries per call. Why do you ask? Hopefully your code can handle any reasonable result size.

Oh, actually, I think that get_shared_link_metadata doesn't give you a list of files in a folder... API v1 has https://www.dropbox.com/developers-v1/core/docs#metadata-link, which should work for you right now, but API v1 is deprecated. I'll check with the team to see if equivalent functionality is available in API v2.

See https://www.dropbox.com/developers/documentation/http/documentation#sharing-get_shared_link_metadata and https://www.dropbox.com/developers/documentation/http/documentation#sharing-get_shared_link_file.

Yes, it's possible to do this, but I don't have any sample code to share.

Ah, I think maybe I understand. * A user clicks the "log in" button in your app. * You take the user through the OAuth flow in the browser (since the Dropbox app is not installed). * If the user isn't already logged in to the Dropbox website, they'll need to enter their username and password to log in. * Now a new user on…

What does your "Login" button do? Just do that again.

You can log a user in whenever you want. Just take the new user through the OAuth flow. Maybe you can be more specific about the problem you're having.

What do you mean by "sign out?" If you want to "forget" a user in your app, just delete the stored access token and stop using the auth'd DbxClientV2 object.

Compare to the much saner https://github.com/rmccue/Requests: $response = Requests::post("https://content.dropboxapi.com/2/files/download", array( 'Authorization' => "Bearer $token", 'Dropbox-Api-Arg' => json_encode(array('path' => '/test.txt')), )); $fileContent = $response->body; $metadata =…

You're not being dense... this is extremely hard to do with curl in PHP. Here's some working code: function dbx_get_file($token, $in_filepath, $out_filepath) { $out_fp = fopen($out_filepath, 'w+'); if ($out_fp === FALSE) { echo "fopen error; can't open $out_filepath\n"; return (NULL); } $url =…

The metadata is in the Dropbox-API-Result header of the response.

Take a look at the "Request and response formats" section at https://www.dropbox.com/developers/documentation/http/documentation. In particular: Content-download endpoints As with content-upload endpoints, arguments are passed in the Dropbox-API-Arg request header or arg URL parameter. The response body contains file…

Hmm. The code in that version looks identical, and there are no other calls to getPath(). Is there any chance you modified the code in AuthActivity.java? I'm afraid I don't have any other ideas.

Could you tell us what version of what SDK you're using? I think based on the stack that you're using some version of the Core API (v1) Android SDK, but it would help to know exactly which version. In the current code for onNewIntent, this is the only call I see to getPath(), which sure looks like it's guarded against null…

I'm not sure why you're getting that error, since you appear to be sending a request body. But note that you're missing this: req.setRequestHeader "Content-Type", "application/json" and this line: req.send (arg) should really be this (but I don't think the extra parentheses are causing issues): req.send arg

Could you share the log here (and the updated code that generates that log)? It's hard to help you debug this without being able to see what's happening.

Have you tried adding the logging I suggested? What does it reveal?

When you say the size is "drastically changed," could you be more specific? What's the value of "size" and how big is the resulting upload? How big is "CHUNK"? One quick debugging tip: try printing out the value of "totalRead" and "cursor" before each call to the API. This might help track down the issue.

[Cross-linking with Stack Overflow: http://stackoverflow.com/questions/37475808/dropbox-file-uploading-not-showing-409-error]

Are you sure? I believe API v1 had the same behavior.

As I said earlier in this thread: "Are you actually uploading new content, or is the new file identical to the old file? (If the content is identical, Dropbox basically ignores the update.)" My guess is that you're not changing the contents of sample.jpg in between upload attempts. If the content is unchanged, there's no…

If the upload succeeds, that means the file was indeed updated (or the contents weren't changed). Some ideas of things to check: * Did you really send updated content via the API? (E.g. maybe you're editing the wrong file, not the one you're actually uploading.) * Are you looking at the right file when you're trying to…

Are you actually uploading new content, or is the new file identical to the old file? (If the content is identical, Dropbox basically ignores the update.) If that's not it, please share some code that can reproduce the issue.

My guess would be that you have a "path" arg of "modified.jpg", and the contents of that file are not the same as the contents of "new.txt" (the file you're uploading). Each time you make this API call, the contents of "new.txt" still don't match the original "modified.jpg", so there's a conflict and your upload gets…