问题标签 [azure-storage-files]

我正在尝试访问我以编程方式上传到天蓝色文件存储的文件。

但是粘贴直接网址时：

知道当我想从 Azure 文件存储下载时如何直接获取该文件吗？

背景：

• Xamrin 表单客户端应用程序
• 带有点网的 Azure 后端
• 使用 Azure 离线数据同步
• 尝试使用 Azure 脱机文件同步

相关的 SO 问题 我在这里问了另外 2 个问题，这些问题与 使用 Azure 文件同步时获取 404有点相关

使用 Azure 文件同步时获得 500

解决方案 如上面第一个链接中所述，即使我不打算为用户使用文件，我也必须为用户实体创建一个存储控制器才能成功登录。

当我在应用程序中进一步工作时，我仍然会收到更多 404 错误，正如我在提琴手中看到的那样。这些是类似的调用，它们希望访问如下 API

GET /tables/{EntityName}/{Id}/MobileServ‌​iceFiles HTTP/1.1

我现在的问题 我是否需要为我的解决方案中的每个实体提供一个存储控制器？可能是从 EntityData 继承的每个实体？

有没有一种方法可以有选择地告诉系统哪些实体将使用文件并仅为它们提供存储控制器？就像，可能是用一些属性标记它们？

参考 我正在使用这篇博文在我的应用程序中实现 Azure 文件同步。

我正在使用 Azure 文件存储来存储一些文件，并且我想在同一个 Azure 文件共享上创建一个包含其中一些文件的 zip 文件。

到目前为止，这是我的代码：

在行上，zip.Create(0);这会创建一个空文件。然后，我继续使用此文件引用来创建一个 zip 文件，并向其中添加内容，但是当它到达时，它会fileStream.CopyTo(entryStream);抛出异常并显示以下消息：

大概是因为文件大小为0，无法自动增加大小。

我可以用 来创建文件int.MaxValue，但是我得到一个 2GB 的文件。我什至无法计算出要添加到档案中的文件的大小并调整文件的大小以将其扩展该数量，因为它是一个 zip，它会压缩和更改文件大小。

我该怎么做呢？

是否可以将 Visual Studio Team Services 构建的输出发布到 Azure 文件存储？我已经查看了Azure 文件复制任务，但除了 Azure Blob 存储或带有此功能的 VM 之外，没有其他方法可以复制到任何内容。我在想我可以使用 AzCopy 来实现这一点，但似乎应该开箱即用地支持它。有任何想法吗？

我们有文件存储帐户来为我们的客户存储文件。但是文件经常崩溃。似乎内容已替换为“\0\0\0\0\0\0”等空字符串。

损坏的文件通常会在几天（或几个月）后被发现。

cloudFile.DownloadText returns string like "\0\0\0\0\0\0".

这是http://www.jssor.com/jssordev/problems*上的示例文件“100days.slider”

我们通过以下 3 种方式将文件保存到 azure 文件存储中，

1. 上传文字cloudFile.UploadText(content, Encoding.UTF8);
2. 从另一个云文件上传dstCloudFile.UploadFromStream(srcCloudFile.OpenRead());
3. 从用户发布的文件上传cloudFile.UploadFromStream(httpPostedFile.InputStream);

有谁知道发生了什么？

检查http://www.jssor.com/danishrabbani上的“full-width-slider.slider”* 这是今天（2016 年 10 月 24 日）一个新的损坏文件。

用户经历了以下 2 个步骤，在第 2 步发现了问题。

1. [OK] 用户在http://www.jssor.com/danishrabbani/full-width-slider.slider/=edit编辑了文件，这意味着它正确读取了文件。

2. [问题] 然后用户从上一页转到http://www.jssor.com/danishrabbani/full-width-slider.slider/=preview 。

两个步骤都读取同一个文件，所以问题可能是由第二次读取引起的。假设用户在步骤 1 和步骤 2 之间保存了数据，那么问题应该是由cloudFile.UploadText(content, Encoding.UTF8);.

编辑 2016-10-26

今天的新空文件“不同大小的照片滑块与文本.滑块”在这里找到http://www.jssor.com/mfleury*

UploadText我们以和两种方式对文件上传进行了调查UploadFromStream，没有出现异常。我认为问题出在 azure 文件存储服务器端或文件存储 SDK 库。

编辑 2016-10-27

今天的新空文件“不同大小的照片滑块.slider”在这里http://www.jssor.com/zubairqd*

编辑 2016-11-08

未引发异常，文件上传始终成功。

用户通常会保存我们演示的副本以开始，dstCloudFile.UploadFromStream(srcCloudFile.OpenRead());

之后，用户在滑块制作器中编辑文件，然后保存文件， cloudFile.UploadText(content, Encoding.UTF8);

我们跟踪了损坏文件的读取，大多数情况下，它发生在 X64 或 WOW64 系统上的 firefox（版本 49）上。所以问题可能是由cloudFile.UploadText(content, Encoding.UTF8);.

另外，大约一年前我的win7（x86）系统发生了这种情况，当时没有lzw压缩。

为了从滑块制作器中保存文件，它将 lzw 压缩数据发送到我们的服务器，然后解压缩，然后cloudFile.UploadText到文件存储。我们确实检查了前 2 个字符是否为“\0\0”，但我们没有找到任何类似的文本。

我按照 Microsoft Azure文档将我的 Xamarin Forms 应用程序与 azure 移动服务集成在一起。我定义了一个数据连接，使用简单的表来定义一些自定义表，并且移动客户端的一切都按预期工作。

今天我想扩展我的后端功能并启用文件存储。我按照此处找到的说明进行操作，一旦我使用 StorageController 创建了一个新的 .NET 服务器后端项目并将其发布到 azure，整个简单表 api 就停止工作。来自移动客户端的所有呼叫都失败并出现以下错误：

The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.

所有mobileClient.GetTable<SomeEntity>().SomeOperationAsync()呼叫都会发生这种情况。

我的猜测是发布自定义后端覆盖了在线生成的简单表格 api......不幸的是，我没有足够的天蓝色云经验来找出我犯了错误的地方。有什么方法可以让自动生成的简易表 api 也适用于文件存储？

我正在尝试在 Fedora 22 上编译 Azure 存储 c++ SDK。我使用的是 gcc 版本 5.1.1-1。当我使用以下命令编译测试应用程序时：

它产生以下错误消息：

我可以在/usr/lib64目录中看到libpthread.so.0库。我需要安装哪个其他库？

我想在嵌套文件夹环境中上传文件。我创建目录和上传文件没有问题，但是在使用嵌套目录时，我在尝试创建文件夹时遇到了存储异常。这是一个代码示例。

我是否必须创建一个为目录创建目录的方法，还是有更简单的解决方案？

我正在寻找一种通过 ARM 模板在 Azure blob 和文件共享存储中创建容器的方法。

目前我有 ARM 模板来配置存储帐户，但我也想在 ARM 中创建容器。

快速提问。我一直在阅读有关 azure blob/文件/磁盘存储选项的大量信息，并且我有一个如此简单的存储要求，以至于我不知道什么是最佳选择。我正在阅读的大部分信息都完全超出了我的想象。

我希望有人能够将视野缩小到更合理大小的优点/缺点。我的情况如下：

我正在构建一个进行图像处理的 API。简而言之，用户对带有特定文本的特定图像发出获取请求以在顶部打印，我的 API 对其进行处理并吐出图像。目前我在 Azure 模拟器上运行，因此图像文件（大约 3 gigs 的 PNG）是从本地路径中提取的。我很快就会部署到一个实时的天蓝色服务器，所以我想将这些图像文件存储在某个地方（而不是将它们放在实际的应用程序文件中）。

到目前为止，我的理解是磁盘和文件选项将允许我保持我的代码相对相同，仍然使用通用文件 I/O 来加载图像路径。磁盘将只允许访问运行此 API 的机器上的数据，这很好，但我不知道拥有磁盘是否有任何好处，这会施加此限制。Blob 存储需要我更改它，但没有太多代码，我预计这不会太困难。

每个不同的选择都有很多细节，以至于我很难做出决定：对于我的情况，这三者之间是否有明确的选择？它归结为更容易吗？性能和成本是重中之重，那么这些方面的优缺点是什么？这确实需要能够扩展到更多图像，但只是在一定程度上。在接下来的几年里，我可以看到它从 3 gigs 图像到 10 gigs 图像，但不会从 3 gigs 到 1000 gigs。