The error message is incorrect when moving files to a non-existed folder in one ADLS Gen2 blob container

[v-kellyluo]

Storage Explorer Version: 1.36.0-dev (100) Build Number: 20240925.3 Branch: rel/1.36.0 Platform/OS: Windows11/Windows 10/Linux Ubuntu 22.04/MacOS Sonoma 14.6.1(Apple M1 Pro) Architecture: arm64/x64/x64/x64 How Found: From running test cases Regression From: Previous release (1.35.0)

Steps to Reproduce

1. Expand one ADLS Gen2 storage account -> Blob Containers.
2. Create a blob container -> Upload a blob.
3. Select the blob -> Click 'Move'.
4. Type a character into the 'Destination directory' field -> Click 'Move'.
5. Click 'Details...' next to the failed activity log.
6. Check whether the error message is 'RenameDestinationParentPathNotFound'.

Expected Experience

The error message is 'RenameDestinationParentPathNotFound'.

Actual Experience

The error message is 'AuthorizationPermissionMismatch'.

[craxal]

@v-kellyluo I am not able to reproduce this issue on 1.35.0, on 20240925.3, or on a local build. I get the expected RenameDestinationParentPathNotFound error. Maybe you need to double-check your permissions?

Either way, this is a message from the service, not something we have any control over.

[v-kellyluo]

Hi @craxal , thank you for the update! I can still reproduce this issue on rel branch, here is the record: In addition, I found that this issue doesn't reproduce if I add myself as owner. In 1.35.0, we don't need to add this access.

[craxal]

@v-kellyluo

• Can you provide app logs, please?
• Are you also able to remove yourself as owner? Does the problem reproduce when you do so?
• Are you using OAuth in both 1.35.0 and the release branch build?

[craxal]

@MRayermannMSFT Also agrees this is not a serious problem. The difference in error message could have something to do with whether OAuth or key is being used, in which case authorization errors can be returned instead of the expected error.

Why different versions would be behaving differently is more of a mystery. Please make absolutely sure you are using the exact same account, the same container, the same credential types, the same blob, and the same input into the destination name.

[craxal]

@v-kellyluo Can you verify that this is still reproducing?

[v-kellyluo]

@craxal ,Yes, verified this issue on the build 20241205.2, it still reproduces.

[craxal]

@v-kellyluo We're still unable to repro on our end. Can you provide the VM you are using to test? Can you also answer the questions I asked above?

[v-kellyluo]

@craxal , Will share the VM on teams.

1. Can you provide app logs, please? Here is the logs: 2024-12-05_184707.zip

2. Are you also able to remove yourself as owner? Does the problem reproduce when you do so? Yes, this issue reproduces if I remove myself as owner.

3. Are you using OAuth in both 1.35.0 and the release branch build?

• If use OAuth in both 1.35.0 and current build, this issue doesn't reproduce on both versions.
• If don't use OAuth in both 1.35.0 and the current build, this issue only reproduces on current build.

[craxal]

I am still unable to reproduce, even on the VM.

If don't use OAuth in both 1.35.0 and the current build, this issue only reproduces on current build.

This is the most interesting detail. What method are you using and what permissions are given with that method?

All in all, it sounds to me like the error you're getting is in fact the correct error message due to a permissions issue of some kind. I don't think we need to worry about spending more time on this unless this throws customers off.