Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Misleading NIO URI format documentation #39579

Open
ejschoen opened this issue Apr 6, 2024 · 6 comments
Open

[BUG] Misleading NIO URI format documentation #39579

ejschoen opened this issue Apr 6, 2024 · 6 comments
Assignees
Labels
Client This issue points to a problem in the data-plane of the library. customer-reported Issues that are reported by GitHub users external to the Azure organization. needs-team-attention This issue needs attention from Azure service team or SDK team question The issue doesn't require a change to the product in order to be resolved. Most issues start as that Storage Storage Service (Queues, Blobs, Files)

Comments

@ejschoen
Copy link

ejschoen commented Apr 6, 2024

Describe the bug

Not really a bug. More a documentation issue, although some additional validation of azb: URI's might help.

The README for NIO documents the URI format as azb://?endpoint=storage-account-name.blob.core.windows.net. It's very easy to think you should create a URI of the form azb://container-name:/path/to/file?endpoint=... This is technically wrong because the container name is in the host name spot and not the first element of the path. However, this works, but only if the file being referenced is in the first container in the list of containers passed to the newFileSystem call when the Azure file system is initialized. The file system will happily create azb://second-container-name:/path/to/another/file?endpoint=... as a path, but that path won't work. It only works if the URI is of the form azb:/second-container-name:/path/to/another/file?endpoint=...

Code Snippet
Add the code snippet that causes the issue.

                    StorageSharedKeyCredential creds = new StorageSharedKeyCredential(keyconfig.get("accountname"),
                                                                                      keyconfig.get("accountkey"));
                    HashMap config = new HashMap();
                    config.put(AzureFileSystem.AZURE_STORAGE_SHARED_KEY_CREDENTIAL, creds);
                    config.put(AzureFileSystem.AZURE_STORAGE_FILE_STORES, azure_containers);
                    FileSystems.newFileSystem(new URI(String.format("azb://?endpoint=%s", azure_endpoint)), 

where azure_containers is something like `"container1,container2"

Then:

path1 = Paths.get(new URI("azb://container1:/path/to/existing-file-in-container1"))
path1.exists() => true

but

path2 = Paths.get(new URI("azb://container2:/path/to/existing-file-in-container2"))
path2.exists() => false

whereas:

path2a = Paths.get(new URI("azb:/container2:/path/to/existing-file-in-container2"))
path2a.exists() => true

Expected behavior
Naively reading the docs for NIO, I'd expect both .exists tests to return true. If I use a single slash after the scheme, it works as expected, but the docs example shows 2 slashes. It does say that the container name has to be the first element of the URI path, but that's a little bit subtle. Some warning that double slashes after the azb: scheme are not needed, and could be harmful would be helpful.

Setup (please complete the following information):

  • OS: Linux
  • IDE: None
  • Library/Libraries: azure-storage-blob-nio
  • Java version: [e.g. 8] 8
  • App Server/Environment: Clojure
  • Frameworks: [None

I

@github-actions github-actions bot added Client This issue points to a problem in the data-plane of the library. customer-reported Issues that are reported by GitHub users external to the Azure organization. needs-team-attention This issue needs attention from Azure service team or SDK team question The issue doesn't require a change to the product in order to be resolved. Most issues start as that Storage Storage Service (Queues, Blobs, Files) labels Apr 6, 2024
Copy link

github-actions bot commented Apr 6, 2024

Copy link

github-actions bot commented Apr 6, 2024

Thank you for your feedback. Tagging and routing to the team member best able to assist.

@ibrandes
Copy link
Contributor

Thanks for filing this issue @ejschoen, could you provide a runnable code snippet so we can verify this behavior with the container path creations?

@ejschoen
Copy link
Author

I did provide a code snippet in my submission above. Maybe I misunderstood what you need--is there a reference to what you expect for code snippets somewhere? Do I need to set up a couple of publicly readable storage containers, or do you maintain some that I can assume exist in a snippet?

@ibrahimrabab
Copy link
Contributor

Hi @ejschoen
We tried to reproduce the issue using what you gave us but we were unable to do so since the snippet you provided did not have a Path.exist() method. How are you checking the existence of the path? Can you provide us a working sample for us to directly run and reproduce?
Thanks!

@ejschoen
Copy link
Author

Apologies. Transcription error while converting code from Clojure to Java. It should have been Files.exists(path1), etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Client This issue points to a problem in the data-plane of the library. customer-reported Issues that are reported by GitHub users external to the Azure organization. needs-team-attention This issue needs attention from Azure service team or SDK team question The issue doesn't require a change to the product in order to be resolved. Most issues start as that Storage Storage Service (Queues, Blobs, Files)
Projects
None yet
Development

No branches or pull requests

3 participants