none
Azure blob's block list is empty, but blob is not empty! How can this be?

    Question

  • One of our storage blobs in an Azure account has an empty block list, although it is non-empty.

    I'm retrieving the block list like this (C#):

    foreach (var block in _cloudBlob.DownloadBlockList(
        BlockListingFilter.Committed, 
        AccessCondition.GenerateLeaseCondition(_leaseId)))
    {
        // ...
    }

    The code in the foreach block is NOT executed. The returned list is empty.

    However, the blob reports that it has a non-zero length when I check:_cloudBlob.Properties.Length

    I can also download the blob and see that it is not empty.

    Am I missing something? How can the block list be empty when the blob is not?!

    It does not matter whether I use BlockListingFilter.Committed,BlockListingFilter.Uncommitted or BlockListingFilter.All; the list is still empty!

    UPDATE

    I have copied this blob to a public container so that this issue can be reproduced by anyone.

    Here's how to reproduce what I'm unable to understand:

    First get blob properties from Azure using the REST API:

    HEAD http://dfdev.blob.core.windows.net/pub/test HTTP/1.1
    Host: dfdev.blob.core.windows.net
    

    Response:

    HTTP/1.1 200 OK
    Content-Length: 66
    Content-Type: application/octet-stream
    Last-Modified: Sat, 02 Feb 2013 09:37:19 GMT
    ETag: 0x8CFCF40075A5F31
    Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
    x-ms-request-id: 4b149a7e-2fcd-4ab4-8d53-12ef047cbfa1
    x-ms-version: 2009-09-19
    x-ms-lease-status: unlocked
    x-ms-blob-type: BlockBlob
    Date: Sat, 02 Feb 2013 09:40:54 GMT
    

    The response headers tell us that this is a block blob and that it has a length of 66 bytes.

    Now retrieve the block list from:

    http://dfdev.blob.core.windows.net/pub/test?comp=blocklist

    Response body:

    <?xml version="1.0" encoding="utf-8"?><BlockList><CommittedBlocks /></BlockList>

    So, the blob does not have any committed blocks, still it has a length of 66 bytes!

    Is this a bug or have I misunderstood something?

    Please help me out!

    • Edited by mwikstrom Saturday, February 02, 2013 10:23 AM
    Friday, February 01, 2013 8:07 PM

Answers

  • Hi,

    I've confirmed with the product team. This is a normal behavior. The x-ms-blob-content-length header is the size of the committed blob. In your case you use Put Blob API so all content is uploaded in a single API and is committed in the same request. As a result in the Get Block List API's response you see the x-ms-blob-content-length header has value of 66 which means the committed blob size.

    We have been aware of the issue that the MSDN document of the Get Block List API is not quite clear on this and will work on it. Thanks.


    Allen Chen
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.


    Friday, February 08, 2013 1:25 AM

All replies

  • Hi,

    When you call PutBlock() method, a new block blob will be created with 0 content length. But only this action won't let block become part ob blob until it commited by the PutBlockList() method. This method actually generates the body in block to present it is a committed block. I think it is by design.

    http://msdn.microsoft.com/en-us/library/windowsazure/ee741643.aspx

    http://msdn.microsoft.com/en-us/library/windowsazure/ee758411.aspx

    Thanks,


    QinDian Tang
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, February 04, 2013 7:29 AM
  • Thank you for your reply. I'm aware that we're supposed to first put blocks and them commit them. But how can the contents of a blob be non-empty while both the committed block list and the uncommitted block lists are empty?

    The blob has been created using a single HTTP PUT request (for block blob).

    The documentation says that it is possible to upload a block blob like this if it is smaller than 64 MB. However, I'd expect that such a blob shall have a non-empty list of committed blocks. Although that is not the case here!

    If this is by design, then this means that the concatenation of committed blocks is not equal to the actual committed content.

    If that is indeed the case, then how shall we determine when we can rely on the committed block list and when we cannot?

    Monday, February 04, 2013 7:42 AM
  • Hi,

    Let me consult internally to see what happens. Will get back to you ASAP.


    Allen Chen
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, February 05, 2013 3:23 AM
  • Hi,

    I've confirmed with the product team. This is a normal behavior. The x-ms-blob-content-length header is the size of the committed blob. In your case you use Put Blob API so all content is uploaded in a single API and is committed in the same request. As a result in the Get Block List API's response you see the x-ms-blob-content-length header has value of 66 which means the committed blob size.

    We have been aware of the issue that the MSDN document of the Get Block List API is not quite clear on this and will work on it. Thanks.


    Allen Chen
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.


    Friday, February 08, 2013 1:25 AM
  • Thank you for your help. It was very valuable to get this confirmation!
    Friday, February 08, 2013 11:01 AM