Over the air download via API fails today, worked yesterday.

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

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?

In future revisions most likely.  This does not bode well for any devices already out in the field.  I will work on fixing TI's code and see what I can do.  Thank you for the help.

Is there a maximum size?  If I am going to be fixing this I would like to do it only once.

Thanks,

Vic

No, there's no maximum size for the link.

Hi Greg, 

I have faced the same problem. There are over 3K of our devices out in the field and we are helpless at this point of time. The size of link until last week was less than 400 bytes and we suddenly see it crossing 550 bytes. We have provided OTA for these 3K devices atleast Twice as of now and no issues until 2 days back.

It will be really helpful if Dropbox can help us by reducing this link length to less than 400 bytes like before for time being or for a few weeks. Meanwhile, We will work towards updating the firmware remotely and resolve this issue in the existing hardware.

Appreciate your earliest support in this regard.

Thanks

Sri

BAB1 No, unfortunately we can't administratively change the length of that link. 

The length of these links can depend on the original file path though, so one solution may be to make that file path as short as possible, in order to get the resulting link short enough to fit in your buffer.

Thanks Greg.

Just tried your suggestion of reducing the file path. It doesn't seem to be effecting the length of link. I am still getting it over 500 bytes. Can you please help me understand how this length has changed only in the last Two days and was less than 400 bytes in the last One year ? Unfortunately my options are Zero with regard to ability to change anything in the firmware of the hardware in field right now. The entire access to the end hardware is now blocked.

Can you please suggest any further alternatives ? 

Thanks.

BAB1 The length of the returned link depends on a few things, including the file path, based on how it's implemented on the Dropbox servers. It's possible the length did increase due to some backend change recently.

I'm checking with engineering to see what may have changed here, and to see if we can potentially revert it, but I can't make any promises with respect to that right now.

Unfortunately, I don't have any other workarounds to offer.