You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Expose way to keep track of a file's upload or download progress #37
Having an optional delegate method argument in the files_upload / files_download methods so that we can update progress UI and whatnot when uploading and downloading files would be really useful.
This is possibly common enough to add special support. But for now, there are some workarounds.
files_download should be easy. It returns the file metadata object and the HTTP response object (from the Requests library). The file metadata object tells you how big the file is. The HTTP response object's raw field is a file-like object, so you can track progress as you repeatedly call read(4096).
files_upload is a little more work: take your original file-like data source, wrap it with your own object, and pass that to files_upload. When files_upload calls your wrapper's read(), you can assume all data read before that point has been uploaded (and perhaps call a delegate).
The assumption (that all the data read before the call to read() has been uploaded) isn't bulletproof, but it might be good enough. The upside is that these wrappers are general-purpose.
In the v1 API, the upload_chunk method returned an offset value - which is essentially the number of bytes uploaded. I use this for a progress bar in a CLI app at present. Does something of the sort exist in v2?
v2 has upload_session_start / upload_session_append / upload_session_finish, but its not exactly for this use-case I don't think. Besides there's still no progress update mechanism for download, so would certainly be useful to get that in there, shouldn't be hard at all.
👍 Yeah it should be straight forward enough. Awesome job on opening the client SDK on github - I have a fork of v1 with a single lonely patch which nowadays will be a pull request 😄
@cakoose I am confused in using the return type of files_download_to_file. as per the documentation dropbox sdk
The return types are metadata and request object. They are returned only after the file gets downloaded.
I don't know how to invoke the read(4096) in the returned request object.
Maybe I don't know how to use this.
Moreover in this case, tuple is returned. But when printing it, I find only the metadata.
and the code for that piece is
So, may be a small snippet on how to use read on the request object would be appreciated
In case of exceptions, like network time out, how to re-run it.( in simple a robust one)
@Lakshman-LD function files_download_to_file have mistake in their doc description.
really returns only FileMetadata. line 259 at base.py: return r[0]
There is need to fix documentation.
The new dropbox.file_transfer API supports progress callbacks for both uploads and downloads through UploadOptions.progress and DownloadOptions.progress.
This is implemented in the new higher-level transfer helpers rather than directly on the generated files_upload / files_download methods.
Activity
cakoose commentedon Dec 16, 2015
This is possibly common enough to add special support. But for now, there are some workarounds.
files_downloadshould be easy. It returns the file metadata object and the HTTP response object (from the Requests library). The file metadata object tells you how big the file is. The HTTP response object'srawfield is a file-like object, so you can track progress as you repeatedly callread(4096).files_uploadis a little more work: take your original file-like data source, wrap it with your own object, and pass that tofiles_upload. Whenfiles_uploadcalls your wrapper'sread(), you can assume all data read before that point has been uploaded (and perhaps call a delegate).The assumption (that all the data read before the call to
read()has been uploaded) isn't bulletproof, but it might be good enough. The upside is that these wrappers are general-purpose.mafrosis commentedon Dec 16, 2015
In the v1 API, the
upload_chunkmethod returned an offset value - which is essentially the number of bytes uploaded. I use this for a progress bar in a CLI app at present. Does something of the sort exist in v2?skela commentedon Dec 16, 2015
v2 has upload_session_start / upload_session_append / upload_session_finish, but its not exactly for this use-case I don't think. Besides there's still no progress update mechanism for download, so would certainly be useful to get that in there, shouldn't be hard at all.
mafrosis commentedon Dec 16, 2015
👍 Yeah it should be straight forward enough. Awesome job on opening the client SDK on github - I have a fork of v1 with a single lonely patch which nowadays will be a pull request 😄
skela commentedon Dec 16, 2015
@cakoose thanks for the workaround, I'll take a look at doing that for now.
skela commentedon Dec 17, 2015
@cakoose your workaround is better than nothing, thanks!
lakshmantgld commentedon Dec 23, 2015
@cakoose I am confused in using the return type of files_download_to_file. as per the documentation
dropbox sdk
The return types are metadata and request object. They are returned only after the file gets downloaded.
I don't know how to invoke the read(4096) in the returned request object.
Maybe I don't know how to use this.
Moreover in this case, tuple is returned. But when printing it, I find only the metadata.
and the code for that piece is
Thanks in advance.
cakoose commentedon Dec 23, 2015
Use
files_downloadinstead offiles_download_to_file.aicpp commentedon May 20, 2016
@Lakshman-LD function files_download_to_file have mistake in their doc description.
really returns only FileMetadata.
line 259 at base.py:
return r[0]There is need to fix documentation.
garrett5688 commentedon May 26, 2016
@aicpp thank you for pointing this out, was driving me crazy
IanButterworth commentedon Jan 4, 2019
Has a way to track download progress with
files_download_to_filebeen found/added?greg-db commentedon Jan 4, 2019
@ianshmean No, unfortunately not.
AndreyVMarkelov commentedon Aug 17, 2026
Closing as completed by #581.
The new dropbox.file_transfer API supports progress callbacks for both uploads and downloads through UploadOptions.progress and DownloadOptions.progress.
This is implemented in the new higher-level transfer helpers rather than directly on the generated files_upload / files_download methods.