我们正在构建一个由Azure存储支持的网站。一个辅助角色有一些文件，它在启动时从blob下载。这些文件一旦存储就永远不会被修改，我们只需将它们拉下来并使用它们。
有时，当尝试从开发存储中下载这些文件时，Storage Emulator服务会返回500个错误。我们可以列出blob中的文件并获取元数据，但不能下载文件本身。我们发现的唯一解决方案是删除blob和重新上载。
还有其他人遇到过这个吗？
更新：1.7 SDK
答案 0 :(得分：5)
C:\Users\<username>\DevelopmentStorageDb201206.mdf文件（其中<username>是受影响用户的名称）; (localdb)\v11.0）; CommitBlockList; SET UncommittedBlockIdLength = NULL更改为SET UncommittedBlockIdLength = 0; 我发现大约每隔七天就会删除一次BLOCK blob
在开发/测试过程中，为了测试目的再次创建这些blob是很痛苦的
试图找到存储模拟器源代码但找不到它。
打开C:\Users\<username>\AppData\Local\DevelopmentStorage的日志记录
将以下内容添加到DevelopmentStorage.201206.config
<LogPath>C:\Users\<username>\AppData\Local\DevelopmentStorage\Logs</LogPath>
<LoggingEnabled>true</LoggingEnabled>
在日志中发现痛苦的等待之后：
DefragmentBlobFiles BlobInfo名称40f5e12f-65a5-4a3a-ae46-41c71c8514c0 / file1.txt，ContainerName storage1，目录c：\ users \ username \ appdata \ local \ developmentstorage \ ldb \ blockblobroot \ 1 \ 12735b4b-f9ed-481b-a091 -78387facf05b，ROFile，RWFile c：\ users \ username \ appdata \ local \ developmentstorage \ ldb \ blockblobroot \ 1 \ 12735b4b-f9ed-481b-a091-78387facf05b \ 1，Size5
我不认为上面的碎片整理会造成任何问题 找到另一个日志：
BlockBlob：加载间隔失败。 IsGC：True，System.Number.ParseDouble中的异常（字符串值，NumberStyles选项，NumberFormatInfo numfmt） 在Microsoft.WindowsAzure.DevelopmentStorage.Store.BlockBlobGarbageCollector.GetTimerIntervalOrDefault（Boolean isGC）
因此对于BlockBlobs这个BlockBlobGarbageCollector会对未提交的块进行垃圾收集。我无处可寻找这些未提交的块经常被垃圾收集的频率。我不认为这甚至导致了这个问题。
另一个日志：
BlockBlob：在有效目录列表中检查目录C：\ Users \ username \ AppData \ Local \ DevelopmentStorage \ LDB \ BlockBlobRoot \ 1 \ 0477877c-4cb3-4ddb-a035-14a5cf52d86f BlockBlob：删除目录C：\ Users \ username \ AppData \ Local \ DevelopmentStorage \ LDB \ BlockBlobRoot \ 1 \ 0477877c-4cb3-4ddb-a035-14a5cf52d86f
上面的日志显示了问题。模拟器必须确定有效的blockblob目录。
检查数据库DevelopmentStorageDb201206的架构。找到了很少的列，例如IsCommitted和UncommittedBlockIdLength。发现ClearUncommittedBlocks正在设置UncommittedBlockIdLength到null。任何未被删除的Blob都具有UncommittedBlockIdLength值0.因此检查存储过程CommitBlockList并将UncommittedBlockIdLength更改为0而不是null。我认为以前版本中的模拟器必须检查IsCommitted和UncommittedBlockIdLength两者以确定有效的阻塞目录，而在此版本中，它可能只检查UncommittedBlockIdLength为null并删除所有那些阻止blob文件。
正如我所说，需要大约七天的时间来确定此解决方案是否能永久修复它。我还有4天时间来验证它。
如果这是一个有效的解决方法，......微软欠我6个小时;）
答案 1 :(得分：1)
我遇到了同样的问题。我怀疑Azure存储模拟器在LocalDB上运行时出现了问题。原因如下：
当您遇到500错误时，使用Management Studio或Server Explorer打开Blob表，并找到有问题的blob的DirectoryPath字段值（它将类似于c：\ users \ username \ appdata \ local \ developmentstorage \ LDB \ blockblobroot \ 1 \ 305469d0-7b68-4b1e-a41a-a429c21b6b9d
使用资源管理器导航到该路径，并注意此目录为空
现在重新上传您的文件并导航到上传到的新目录，注意有您的文件
那么，现在的问题是为什么blob文件会消失？
答案 2 :(得分：1)
我没有解决方案，但我可以补充一点，当存储模拟器的后备存储是SQL Server 2012时，也会发生这种情况。我们反复看到过这种情况。一切都很好，然后blob消失了。我们的经验是，当数据库引用持续存在时，所有或几乎所有blob都会从文件系统中消失。不知道为什么会发生这种情况 - 没有明显的促成事件。
答案 3 :(得分：0)
我也看到Storage Emulator偶尔会返回有效请求。但通常重试请求将工作正常。始终建议重试失败的请求，除非响应指示请求无效（在这种情况下，重试无论如何都不起作用）。即使您使用云存储，有时它仍可能遇到临时网络不可用等问题。事实上，建议对所有与网络相关的操作使用重试策略。
此外，如果您使用.NET存储客户端库，则可以利用内置重试策略：http://blogs.msdn.com/b/windowsazurestorage/archive/2011/02/03/overview-of-retry-policies-in-the-windows-azure-storage-client-library.aspx。
最诚挚的问候，
徐明。答案 4 :(得分：0)
解决此问题的更简单方法可能是升级到Azure SDK 1.8 - 因为我从1.7升级（从2012-11-23，大约两周前），我的blob不再消失。
即使决定使用旧库，您也可以利用新的存储模拟器 - 实际上这些库是并排安装的，只有模拟器升级（即新版本替换旧版本）但它们仍然是与旧版本兼容。例如，我现在正在使用新的存储模拟器，但我仍然在我的.NET项目中引用1.7库。
更新2013-08-30 18:00 UTC 我再次使用Azure SDK 2.0出现此问题 - 几周后我写了blob，几分钟后我获取HTTP 500 。我想知道这个行为是否是由我的存储模拟器的某些特性（例如太多的blob和/或容器）触发的 - 在这方面我想补充一点，我通过重命名自模式以来的数据库文件从Storage Emulator 1.8升级（与Visual Studio相比似乎是相同的，但也许我错过了一些重要的东西。
我现在正在评估是否升级到Azure SDK 2.1并希望修复此问题或切换到使用真实存储帐户进行开发。
更新2013-09-02 18:00 UTC 由于以下原因，我决定使用真实存储帐户：