Node.js SDK中BlobURL.startCopyFromURL的预期响应？

问题描述

某些上下文：

我目前有代码将blob从我的Azure存储帐户中的一个已提交的blob复制到同一个blob中存储帐户。例如：它复制"raw / foo.jpg"。 to"archive / foo.jpg"

I currently have code that copies a blob from one committed blob in my Azure Storage account to another blob in the same storage account. For example: It copies "raw/foo.jpg" to "archive/foo.jpg"

以下是此代码的示例，使用@ azure / storage-blob NPM软件包的版本10.3.0。

Below is an example of this code, using version 10.3.0 of the @azure/storage-blob NPM package.

let { copyStatus } = await destinationBlobURL.startCopyFromURL(
  Aborter.none, 
  sourceBlobURL.url
);

目前，已解决的响应的"copyStatus"总是被设定为"成功"，并且blob确实按预期复制。但是，我发现contentStatus可能是"待定"，"成功"，"已中止"，"b $ b"或"失败"等。 - 基于此文档：  https://docs.microsoft.com/en-us/javascript/api/@azure/storage-blob/copystatustype

Currently, the resolved response's "copyStatus" is always being set to "success," and the blob indeed gets copied as expected. However, I see that contentStatus could potentially be "pending", "success", "aborted", or "failed" – based on this documentation: https://docs.microsoft.com/en-us/javascript/api/@azure/storage-blob/copystatustype

问题：

1. 鉴于方法的命名（ 开始 CopyFromURL ，而不是
   copyFromURL ）以及存在"待定"  CopyStatusType的事实，是否安全假设可能有一段时间初始copyStatus不是"成功"？什么因素影响初始响应是否包括
   copyStatus of"pending"？与"成功"相比？
2. 是否有计划将重命名的功能添加到JS SDK？ 

1. Given the naming of the method (startCopyFromURL, rather thancopyFromURL) and the fact that there is a "pending" CopyStatusType, is it safe to assume that there may be a time where the initial copyStatus IS NOT "success"? What factors go into whether or not the initial response includes a copyStatus of "pending" versus "success"?
2. Are there any plans to add the capability to rename a Blob to the JS SDK? 

推荐答案

这篇关于Node.js SDK中BlobURL.startCopyFromURL的预期响应？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！