[FEATURE REQUEST] OpenRead(): loop downloads for Read() calls larger than internal buffer

Describe the bug We discovered an issue that when we use OpenRead on BlockBlobClient, the returned stream doesn’t handle reads of more than 4mb well. When reading more than 4mb, it only reads 4mb:

Expected behavior I expect that when I read the entire length of the stream into a buffer, it reads the entire stream

Actual behavior (include Exception or Stack Trace) The current behavior seems to be that even when you pass a number larger than 4mb to the read method, it only reads 4mb.

To Reproduce Use the following snippet to download a file larger than 4mb from a blob container:

 var connectionString = "<connectionstring>";
 var blobContainerName = "<containername>";
 var blobName = "<blobName>";
 var targetPath = "<targetPath>";

 var blobClient = new BlobServiceClient(connectionString);
 var blobContainer = blobClient.GetBlobContainerClient(blobContainerName);
 var blob = blobContainer.GetBlockBlobClient(blobName);

 using (var stream = blob.OpenRead())
 {
    using (var destStream = new System.IO.FileStream(targetPath, System.IO.FileMode.Create, System.IO.FileAccess.ReadWrite))
    {
        byte[] buffer = new byte[stream.Length];
        var read = stream.Read(buffer, 0, (int)stream.Length);
        destStream.Write(buffer, 0, (int)stream.Length);
    }
}

Environment:

• Name and version of the Library package used:Azure.Storage.Blobs 12.7.0

[tg-msft]

Hi folks – I don’t think we should make this change for a couple of reasons:

• We don’t like to redefine semantics for .NET types in Azure libraries. Stream.Read has behaved like this forever. Even FileStream.Read cited above does not always return the number of bytes requested (reference source).
• If we were to implement this, I think it should be a separate BlockingRead method rather than a mode of the Stream. I’d rather be very explicit about APIs that could negatively impact performance. That idea should be filed in https://github.com/dotnet/runtime for the .NET team to evaluate, if desired.
• The workaround of wrapping in a “blocking Stream” is straightforward and not too onerous when this behavior is required.

[jaschrep-msft]

Reopening as a feature request to loop current Read()/ReadAsync() implementation, rather than force the caller to do so.