Azure blob 的阻止列表为空，但 blob 不为空!怎么会这样？

Question

这个问题简而言之:

可以使用单个 PUT 请求创建 block blob。这将创建一个包含已提交内容的 Blob，但该 Blob 不会有任何已提交的 block !

这意味着您不能假设提交的 block 的串联与提交的内容相同。

使用 block blob 时，您必须特别注意具有空 block 列表的 blob，因为此类 blob可能为空，也可能为空!

<小时/>

原始问题:

我们的 Azure 帐户中的一个存储 blob 具有空的阻止列表，尽管它不是空的。

我正在检索阻止列表，如下所示 (C#):

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

foreach block 中的代码不会被执行。返回的列表为空。

但是，当我检查时，blob 报告其长度非零:_cloudBlob.Properties.Length

我还可以下载 blob 并看到它不为空。

我错过了什么吗？当 blob 不是空的时候， block 列表怎么可能是空的？!

无论我使用BlockListingFilter.Commited、BlockListingFilter.Uncommissed还是BlockListingFilter.All都没有关系；列表仍然是空的!

更新

我已将此 blob 复制到公共(public)容器中，以便任何人都可以重现此问题。

以下是重现我无法理解的内容的方法:

首先使用 REST API 从 Azure 获取 blob 属性:

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

回应:

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

响应 header 告诉我们这是一个 block blob，长度为 66 字节。

现在从以下位置检索阻止列表:

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

响应正文:

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

因此，该 blob 没有任何已提交的 block ，但其长度仍然为 66 字节!

这是一个错误还是我误解了什么？

请帮帮我!

更新2

我发现如果我像这样上传 blob:

container.GetBlockBlobReference("put-only")
    .UploadFromStream(File.OpenRead("test-blob"));

...然后将单个 PUT 请求发送到 Azure，并且 blob 获得一个空的阻止列表(就像上面一样)。

但是，如果我像这样上传 blob:

var blob = container.GetBlockBlobReference("put-block");
string blockId = Convert.ToBase64String(Guid.NewGuid().ToByteArray());
blob.PutBlock(blockId, File.OpenRead("test-blob"), null);
blob.PutBlockList(new string[] { blockId });

...然后两个请求被发送到 Azure(一个用于放置 block ，另一个用于放置 block 列表)。

第二个 blob 获取非空阻止列表。

为什么单个 PUT 不会产生阻止列表？

我们不能相信 blob 的已提交 block 的串联等于 blob 的实际内容吗？!

如果不是，我们如何确定阻止列表何时正常、何时不正常？

更新3

我已经为此实现了一个解决方法，我认为在我们遇到此问题的情况下就足够了。如果我们发现一个空的 block 列表和一个大于零的 blob 长度，那么我们将假设一切正常(尽管实际上并非如此)，然后继续使用 Put Block 和 Put Block List 重写该数据下次有机会。

然而，虽然这在我们的例子中可以解决问题，但非空 block blob 可以有一个空的已提交 block 列表仍然非常令人困惑!

这是 Azure 的设计初衷吗？谁能解释一下这是怎么回事？

更新4

微软 confirmed this issue on the MSDN forums也。引用陈艾伦的话:

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.

Answer 1

正如您在测试中所确定的那样，查询使用 Put Blob 上传的 block blob 的 block 列表将返回一个空列表。这是设计使然。

存储客户端库中的UploadFromStream API 在决定是使用单个 Put Blob 操作还是使用一系列 Put Block 操作和后跟 Put Block 列表来上传 Blob 之前，会进行多项检查。更改此行为的一个属性是 SingleBlobUploadThresholdInBytes .