Skip to content

Commit

Permalink
[Storage] [DataMovement] [Docs] Known Limitations (Azure#47999)
Browse files Browse the repository at this point in the history
* Initial commit

* feedback

* small wording change
  • Loading branch information
nickliu-msft authored Jan 28, 2025
1 parent ecbf39e commit 61f9e88
Showing 1 changed file with 36 additions and 1 deletion.
37 changes: 36 additions & 1 deletion sdk/storage/Azure.Storage.DataMovement/KnownIssues.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,4 +26,39 @@ The Azure Storage REST service has various limitations as to the size of request

### Resume Behavior when Client Options are set

When calling `*StorageResourceProvider.FromClient` with a Storage Client (e.g. `BlobBaseClient`, `ShareFileClient`) initialized with `*ClientOptions` (e.g `BlobClientOptions`, `ShareClientOptions`). It is NOT guaranteed that properties set within the `*ClientOptions` will be respected when resuming a transfer.
When calling `*StorageResourceProvider.FromClient` with a Storage Client (e.g. `BlobBaseClient`, `ShareFileClient`) initialized with `*ClientOptions` (e.g `BlobClientOptions`, `ShareClientOptions`). It is NOT guaranteed that properties set within the `*ClientOptions` will be respected when resuming a transfer.

### Encryption Scope Support

There is currently no support to specify an encryption scope for operations such as uploads, downloads, or copies.

### Recursive Directory Disable Support

Currently there is support for transferring entire directories, including all subdirectories and files within them. However, we do not offer an option to disable directory recursion. This means that users cannot copy only the files in a folder without also copying its subdirectories.

### Blob to Share File with OAuth/Entra ID

There is currently no support for transferring data from an Azure Storage Blob to Azure Storage Shares using authentication based on Microsoft Entra ID.

### Resume Transfers started from any Beta version/Deprecated package

Transfers initiated with any beta version of the DataMovement library cannot be resumed due to a schema version change from string to int, which may lead to unexpected errors. Additionally, transfers from the deprecated Microsoft.Azure.Storage.DataMovement package also cannot be resumed.

### Blob Tag Support

There is currently no support for managing or utilizing blob tags. This means users cannot add, retrieve, or manage blob tags during a transfer.

### Public URL Copying

There is currently no support for copying blobs via Public URLs. However, the library does support copying Azure Storage URLs, which can be used for moving data within the Azure Storage ecosystem.

### Copy with a AzureSasCredential

There is currently no support for service-to-service copy given a client that was initialized with a AzureSasCredential from `BlobStorageResourceProvider.FromClient` and/or `ShareStorageResourceProvider.FromClient`.
Here are two alternatives:
1. Use `BlobsStorageResourceProvider(AzureSasCredential)` / `ShareFilesStorageResourceProvider(AzureSasCredential)` to authenticate and then create StorageResource.
2. Initialize a client with a Uri that has a SAS included in the Uri if you still want to use `BlobStorageResourceProvider.FromClient` and/or `ShareStorageResourceProvider.FromClient`.

### Fresh transfer vs Resumed transfer Performance

The performance of resumed transfers is currently lower than that of fresh transfers. This is due to fetching source properties on Resume.

0 comments on commit 61f9e88

Please sign in to comment.