You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
az feedback auto-generates most of the information requested below, as of CLI version 2.0.62
Related command
az storage fs undelete-path
Describe the bug
az storage fs undelete-path is not encoding the --deleted-path-name parameter. If the path has special characters then the call fails with 'The soft deleted blob was not found'.
To Reproduce
Take the following deleted path (output from az storage fs list-deleted-path) which has '%' characters in the blob name:
{
"deletedTime": "2022-07-01T20:24:09+00:00",
"deletionId": "133011806490739084",
"fileSystem": "pubcontainer",
"name": "t=2021-11-13 06%3A29%3A05.38 - Copy.txt",
"remainingRetentionDays": 6
}
Now try to undelete this blob:
az storage fs undelete-path -f pubcontainer --deleted-path-name 't=2021-11-13 06%3A29%3A05.38 - Copy.txt' --deletion-id "133011806490739084" --account-name [accountname] --auth-mode login
You will receive the error 'The soft deleted blob was not found'. Now, encode the blob path and try again:
az storage fs undelete-path -f pubcontainer --deleted-path-name 't%3D2021-11-13%2006%253A29%253A05.38%20-%20Copy.txt' --deletion-id "133011806490739084" --account-name [accountname] --auth-mode login
This time the undelete succeeds.
Expected behavior
The expectation is that CLI will do the HTM encoding of the undelete-path for you. The Undelete Blob API documentation states "the path, which is passed in the x-ms-undelete-source header, must be percent encoded." CLI is wrapping the REST API and should know that this API requires this to be encoded just like it knows that it needs to encode the request URL. Also the following documentation has this comment:
Related command
az storage fs undelete-path
Describe the bug
az storage fs undelete-path is not encoding the --deleted-path-name parameter. If the path has special characters then the call fails with 'The soft deleted blob was not found'.
To Reproduce
Take the following deleted path (output from az storage fs list-deleted-path) which has '%' characters in the blob name:
{
"deletedTime": "2022-07-01T20:24:09+00:00",
"deletionId": "133011806490739084",
"fileSystem": "pubcontainer",
"name": "t=2021-11-13 06%3A29%3A05.38 - Copy.txt",
"remainingRetentionDays": 6
}
Now try to undelete this blob:
az storage fs undelete-path -f pubcontainer --deleted-path-name 't=2021-11-13 06%3A29%3A05.38 - Copy.txt' --deletion-id "133011806490739084" --account-name [accountname] --auth-mode login
You will receive the error 'The soft deleted blob was not found'. Now, encode the blob path and try again:
az storage fs undelete-path -f pubcontainer --deleted-path-name 't%3D2021-11-13%2006%253A29%253A05.38%20-%20Copy.txt' --deletion-id "133011806490739084" --account-name [accountname] --auth-mode login
This time the undelete succeeds.
Expected behavior
The expectation is that CLI will do the HTM encoding of the undelete-path for you. The Undelete Blob API documentation states "the path, which is passed in the x-ms-undelete-source header, must be percent encoded." CLI is wrapping the REST API and should know that this API requires this to be encoded just like it knows that it needs to encode the request URL. Also the following documentation has this comment:
https://docs.microsoft.com/en-us/rest/api/storageservices/Naming-and-Referencing-Containers--Blobs--and-Metadata
Certain characters must be percent-encoded to appear in a URL, using UTF-8 (preferred) or MBCS. This encoding occurs automatically when you use the Azure Storage client libraries.
While this is speaking about the request URL I feel like the same should happen for HTTP request header values that need to be encoded.
Environment summary
az --version
azure-cli 2.37.0
core 2.37.0
telemetry 1.0.6
Extensions:
storage-preview 0.8.3
Dependencies:
msal 1.18.0b1
azure-mgmt-resource 21.1.0b1
Python location 'C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe'
The text was updated successfully, but these errors were encountered: