アズールブロブのブロックリストは空ですが、ブロブは空ではありません！どうすればいいの？一言で言えば

Question

この問題は：

ブロックブロブ単一PUT要求を使用して作成することができます。これにより、コミットされた内容のブロブが作成されますが、ブロブにはコミットされたブロックがありません！

これは、コミットされたブロックの連結がコミットされたコンテンツと同じであると想定できないことを意味します。

ブロックブロブを扱うときは、空白のブロックリストを持つブロブに注意を払う必要があります。そのようなブロブはであるため、が空であることがあります。

---

元の質問：それは非空であるものの、当社のストレージブロブの

一つAzureのアカウントでは、空のブロックリストを持っています。

私は、この（C＃の）のようなブロックリストを取得しています：

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

foreachブロック内のコードは実行されません。返されるリストは空です。しかし

、私がチェックしたときに、それが非ゼロの長さを持っていることをブロブレポート：_cloudBlob.Properties.Length

私もブロブをダウンロードし、それが空でないことがわかります。

何か不足していますか？ブロブが空でない場合、どのようにブロックリストを空にできますか？

BlockListingFilter.Committed,BlockListingFilter.UncommittedまたはBlockListingFilter.Allを使用するかどうかは関係ありません。リストはまだ空です！

UPDATE

この問題は、誰にでも再現できるように、私は公共のコンテナに、このブロブをコピーしました。ここで

は、私が理解することができないんだものを再現する方法は次のとおりです。

まず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 

レスポンスヘッダこれがブロックブロブであり、長さが66バイトであることを教えてください。

今からブロックリストを取得：

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

レスポンスボディ：

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

ので、ブロブがコミットさのブロックを持っていない、まだそれは、66バイトの長さを持っています！

これはバグですか、何か誤解していますか？

私を助けてください！

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

...その後、単一のPUT要求はアズールに送られ、ブロブが空を取得します。私は、私はこのようなブロブをアップロードする場合は検出されませんでした

UPDATE 2

ブロックリスト（上記と同様）。私はこのようなブロブをアップロードする場合

しかし、：

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 }); 

...その後、2つの要求は、Azureの（ブロックリストを置くためのブロックと別のものを置くための1）に送信されます。

2番目のBLOBは、空でないブロックリストを取得します。

なぜ1つのPUTでブロックリストが生成されないのですか？

ブロブのコミットされたブロックの連結がブロブの実際のコンテンツと等しいことに頼ることはできませんか？

もしそうでなければ、ブロックリストがいつOKであるか、それがいつではないかを判断する必要がありますか？

UPDATE 3

私は、我々はこの問題が発生した場合には十分だと思い、このための回避策を実装しました。空のブロックリストとBLOBの長さがゼロよりも大きいことが分かった場合は、すべてがOKであると仮定して（実際にはそうではありませんが）、Put BlockとPut Block Listを使用してそのデータを書き直します次の機会。

しかし、これは私たちの場合のトリックを行いますが、空でないブロックブロブにコミット済みブロックの空のリストを持たせることは非常に混乱しています!!

これはAzureでのデザインですか？誰でも何が起こっているのか説明できますか？

UPDATE 4

マイクロソフトconfirmed this issue on the MSDN forumsすぎ。アレン・チェンからの見積もり：

私は製品チームに確認しました。これは正常な動作です。 x-ms-blob-content-lengthヘッダーは、コミットされたBLOBのサイズです。あなたの場合は、すべてのコンテンツが単一のAPIにアップロードされ、同じリクエストでコミットされるように、Put Blob APIを使用します。その結果、Get Block List APIの応答では、x-ms-blob-content-lengthヘッダーの値が66で、コミットされたBLOBサイズを示しています。

私たちは、ブロックリスト取得APIのMSDNドキュメントがこれではっきりしていないという問題を認識しており、これで問題なく動作します。

Answer 1

Put Blobを使用してアップロードされたブロックブロブのブロックのリストを照会すると、空のリストが返されます。これは設計によるものです。

Storage Client LibraryのUploadFromStream APIは、1つのPut Blob操作または一連のPut Block操作の後にPut Block Listを使用してBLOBをアップロードするかどうかを決定する前に2つのチェックを行います。この動作を変更するプロパティの1つはSingleBlobUploadThresholdInBytesです。