API - downloading files bigger than 4GB

[Roel V.]

Are there any restrictions on the size of files downloaded via the HTTP API?

I have a QNAP NAS that tries to sync with my Dropbox account. About 340GB of it works fine; the last 50 GB (spread over 10 files) doesn't. All files that fail are bigger than 4GB. Through some spelunking in the filesystem of the NAS, I've found a log file that says , essentially 'socket is closed prematurely'. I don't have access to the code that is generating this message, nor do I have any first-hand experience writing code against the Dropbox API.

It seems to me that somewhere, someone is using a 32-bit integer to keep track of how much has already been downloaded and when that fails, the whole download fails. So, my question is (to try to find out on which side the problem is): is it possible to download files bigger than 4GB through the HTTP api, or should the application do something special (like chunked downloads or so)? Thanks

[Greg-DB · Accepted solution]

There isn't a file size limit on downloads, but the HTTP requests themselves can time out if they take a long time. The "content-download endpoints", such as /2/files/download, do support Range Retrieval Requests though. That is a way of downloading portions of a file at a time, so it can be used to help avoid problems like this when downloading large files. This is something the developer of the app would need to implement.

However, from the information you shared I can't be sure if that's the actual issue. Since you mentioned all of the failures occur over 4GB, the issue may actually be with the local filesystem itself. For example, I believe FAT32 only supports files up to 4GB. That's outside the scope of Dropbox API support though, so I can't offer much insight on that.

[Roel V.]

Thanks Greg, that's useful to know - and it gives me a convenient place to start looking in the documentation if it comes to having to convince the customer support rep they have to escalate. Since I posted I did a more thorough check of the data and it turns out there are no files between 1 and 4 gb (just a weird coincidence), so it could indeed still be a timeout issue.