Files larger than 4MB cannot be downloaded

[vsosinga]

Files larger than 4MB cannot be download from Umbraco. When opening a large file it seems to be cut off resulting in a corrupt download.

To reproduce:

1. Create an empty Umbraco project
2. Add UmbracoFileSystemProviders.Azure & UmbracoFileSystemProviders.Azure.Media v2.0.0-beta1
3. Configure a default Azure blob storage
4. Upload a file larger than 4MB
5. Try to download the uploaded file

Uploaded file:

In the blob storage:

Downloaded file:

This issue seems to be introduced with pull request #156 .
The same test case on v2.0.0-alpha5 gives no problems.

[Jeavon]

Thanks @vsosinga I'll investigate this

[timeverts]

I can confirm the same issue here running UmbracoFileSystemProviders.Azure v1.1.0. Files larger than 4MB seem to upload fine, but do not download beyond 4MB of data. This is even visible in the CMS.

If I hit the URL of the image directly in the blob, the full image loads fine.

I believe the same issue is also affecting PDF files larger than 4MB. The PDF uploads fine and can be read directly from the blob storage URL, but when trying to open the PDF from the Umbraco URL, a 'Failed to load PDF document.' is returned.

Hope you can resolve this soon, as it is preventing us from migrating to Azure Blob storage for several of the Umbraco 7 sites of our clients.

[c9mb]

FWIW - I am running UmbracoFileSystemProviders.Azure 1.0.3 with Umbraco 7 (Umbraco-Cloud) and downloading 28MB video files without issue - perhaps in the recent update?

[timeverts]

@c9mbundy, @Jeavon, I just downgraded to v1.0.3 with Umbraco 7 (native) and can also confirm that the bug is not present in that version. So just summarizing, UmbracoFileSystemProviders.Azure v1.0.3 works fine, but UmbracoFileSystemProviders.Azure v1.1.0 does not.

I did some more investigating of the differences between the two versions and found that there was a commit made for v1.1.0 that changed the way files are read, using the CloudBlob.OpenRead() method rather than streaming them from memory. From doing some Googling, I think that in certain configurations this method has a limit of 4MB of read data (see this example and and this one and this one) and reading files larger than that may need to use multiple appended chunks.

So @Jeavon, I reckon this is a good starting point for getting this problem rectified. Hope you're able to resolve soon.

[Jeavon]

This change was reverted in 2.0.0-beta2, 2.0.0 and will be in 1.1.1

[Jeavon]

v1.1.1 also now released