You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
Over the air download via API fails today, worked yesterday.
Hi,
I have an embedded device that downlopads firmware updates over the air via the DropBox API. Downloads worked fine yesterday, and fail today. The code has not changed since then, and I even went back to a revision built a few months ago, and it fails in exactly the same way. I am using a Texas Instruments CC3200 processor. I use the TI library for the OTA process. It can list the files in the repository, but when I try to access them via the link provided the device just hangs. It subsequently reboots. Here is some diagnostic output from the process.
sl_extLib_OtaRun: call OtaClient_ConnectServer OTA server=api.dropbox.com
OtaClient_ConnectServer: http_connect_server api.dropbox.com
[00:00:11.0967] OTA run (0)
sl_extLib_OtaRun: OtaClient_UpdateCheck, vendorStr=3.2.0
OtaClient_UpdateCheck: call http_build_request /1/metadata/auto/
CdnDropbox_SendReqDir: uri=/2/files/list_folder
metadata file=/3.2.0/f00_sys_servicepack.sig, size=256
metadata file=/3.2.0/f43_sys_servicepack.ucf, size=31348
metadata file=/3.2.0/f80_sys_mcuimgA.bin, size=151300
metadata file=/3.2.0/f80_www_logo.png, size=18406
metadata file=/3.2.0/f80_www_main2.html, size=5830
sl_extLib_OtaRun: OtaClient_UpdateCheck, numUpdates=5
[00:00:12.0260] OTA run (0)
sl_extLib_OtaRun: OtaClient_GetNextUpdate: file=/3.2.0/f00_sys_servicepack.sig, size=256
OtaClient_ResourceMetadata: call http_build_request /1/media/auto
OtaClient_ResourceMetadata: file flags=0,metadata flags=0
OtaClient_ResourceMetadata: remove old signature file /sys/servicepack.sig
CdnDropbox_SendReqFileUrl: uri=/2/files/get_temporary_link
[00:00:12.0556] OTA run (0)
sl_extLib_OtaRun: ResourceMetadata CDN file URL = https://dl.dropboxusercontent.com/apitl/1/AAAPogfVrgUuU60x7jjBJL-jMrYmSHG0O8Gb_ReadFileHeaders: domain=dl.dropboxusercontent.com, file=/apitl/1/AAAPogfVrgUuU60x7jjBJL-jMrYmSHG0O8GbVwAf7iHMQOISR2yPAH3YGlgsUr
After the last line the device hangs until the system watchdog reboots it, then the process repeats. Any idea what I might be running into?
Thanks,
Vic Berry
- Greg-DB
Dropbox Staff
It looks like the call to /2/files/get_temporary_link itself is succeeding, since it is showing the retrieved /apitl link. It looks like the log might be cut off unfortunately though.
I just retrieved an /apitl link from /2/files/get_temporary_link myself and it seems to be working. Can you get a fresh one from your app and try it manually (perhaps with any additional verbose logging possible) to see if it's working on your side, or what it's returning that might be causing issues in your app?
What I have seen on my side is that the filename returned is 553 bytes in length. The TI code has a buffer length of 512. This would most certainly cause an issue. How big is the url you received when you retrieve the apitl link?
Thanks in advance,
Vic
- Greg-DB
Thanks for the additional information.
The length of the returned link can depend on the length of the original file path (as well as potentially other factors), so we can't guarantee any particular maxmimum length unfortunately. (For reference, mine is also coming out longer than 512 bytes.)
So, this may have just been a result of the file path getting longer and resulting in a URL larger than that buffer size. I'm afraid I don't have a solution on the API side, since the link can be expected to get that big. Are you able to increase the buffer size?
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
