[blob]: enable cross account async copy (same server)

Which service(blob, file, queue, table) does this issue concern?

Blob

Which version of the Azurite was used?

3.8.0

Where do you get Azurite? (npm, DockerHub, NuGet, Visual Studio Code Extension)

DockerHub

What’s the Node.js version?

What problem was encountered?

copying a blob which exists in a different storage account does not work and instead returns a 404. it turns out this is due to https://github.com/Azure/Azurite/blob/master/src/blob/handlers/BlobHandler.ts#L627, which explicitly returns blobNotFound in the case that the source storage account isn’t the same as the destination storage account. as it appeared to handle this fine all the way down the stack (at least in the Loki provider), i removed the comparison and built a new local image. upon rerunning our local tests this worked fine, so this is more of a question.

is cross-account blob copy explicitly disabled? it appears to be handled in the backend.

Steps to reproduce the issue?

• setup 2 storage accounts
• create a blob on account 1
• attempt to copy the blob to account 2 using account 1 as the copy source

Have you found a mitigation/solution?

locally i was able to just remove the offending line as described above. any reason this couldn’t be included in master?

[XiaoningLiu]

Glad to see your contribution! There are some scenarios about copy blob.

Scenarios:

1. Copy blob from same account in same Azurite instance;
2. Copy blob from another account in same Azurite instance;
3. Copy blob from another account in another Azurite instance;
4. Copy blob from external accessable URL resource; e.g from publich downloadable resource

Current we only support scenario 1. And the goal here is to support scenario 2.

There are some potential ideas for the implementation.

1. Take scenario 2, 3 & 4 as the same. Azurite sends out HTTP GET request against copySourceURL to download from source. This will be a “real” data copy, while existing async copy blob implementation just copys the metadata reference. It’s another topic to maintain the async copy status and scheduling the copy, handle the exceptions when download request aborted.
2. Only support scenario 2 as first step. Check the source blob is under same Azurite instance (by checking it’s the same address and port?). Then send out a HEAD/GET request to copySourceURL to validate access without downloading any HTTP payload by checking HTTP status code should be 200. Then copy metadata reference like current implementation. When copying metadata reference some properties should be updated accordingly, such like account name.

Seems idea 2 is more easy to consume.

[patrickcarnahan]

I’m happy to do whatever is most helpful. It seems like going the extra mile isn’t considerably more work, but I’ll start with your suggestion and we can go from there.

Thanks for this project! Our test runs are much more reliable.