1
votes

When I open a blob container in Azure Storage Explorer, sometimes it lists just a subset of the blobs the container contains. How to make it list all of them? I tried refreshing, searching for the blob name prefix, nothing helped. Sadly, source code is not available for now and I did not find any info on its internal working apart from that it is an Electron app, so it would be hard to dig into the problem from this direction.

I cannot reproduce the problem, it pops up just from time to time. Currently, I am playing with a container where Storage Explorer lists just a single file of 169 KB and displays "Showing 1 to 1 of 1 cached items" at the bottom, but when I click the Folder Statistics button in the toolbar, the Activities window displays "Statistics for devstoreaccount1/palecblobcontainer: 5 blobs; 588,270 bytes (not including snapshots)".

When I list the blobs using the REST API, I get them all. I.e. I view http://127.0.0.1:10000/devstoreaccount1/palecblobcontainer?restype=container&comp=list in my browser and all 5 blobs are listed in the resulting XML. I got the URL of the container by clicking Copy URL in the Storage Explorer toolbar, removing the path to the blob and adding the query string.

I have observed this not only using Storage Emulator, but even the actual Azure Storage. Every time I'd run into this issue, it persisted even after Storage Explorer restart and deletion of %AppData%\StorageExplorer and even after detaching and reattaching the storage account, so it seems caching is not the problem. I found a similar issue on GitHub related to pagination, but in my case the observed counts are consistent and very low, so that all the blobs fit on one page.

How to make Storage Explorer work again once it stops displaying some blobs? If it is a bug, is there a work-around? Is there a reasonable way I can dig deeper into the issue? I'm using Storage Explorer 1.8.1 on Windows 10.

1
what did you end updoing?Alex Gordon
Till today, I had not found a satisfactory solution. Today, I read my question again and got an idea to use Fiddler and it helped. Posted an answer, @l--''''''---------''''''''''''.Palec

1 Answers

1
votes

Storage Explorer uses the REST API under the hood. When a blob container is opened or refreshed, the request path is /devstoreaccount1/palecblobcontainer?restype=container&comp=list&maxresults=1000&delimiter=%2F.

In my case, the problem is the delimiter=%2F part, where %2F is URL-encoded slash. Without that parameter, the API response contains all the blobs, but when the parameter is included, only the ones listed in Storage Explorer are returned.

When I upload another file (an arbitrary desktop.ini) in the root of the container, it looks like this:

When I delete the .safe blob, the 404 blob is listed (and desktop.ini is still listed). When I delete 404, 404.safe is listed. When I rename 404.safe to 404.safe_, chci-vuz-skoda is listed.

When listing a folder containing a subfolder having empty name, the API does not list the empty-named folder and displays its first blob instead. This is probably a bug of the REST API (or some code beneath). I'm not sure if this is a bug of the list or if empty segments should cause the upload of such a blob to fail. I did not manage to create such a blob using Storage Explorer and documentation of blob names limitations does not talk about such limitations.

To work with the blobs in an empty-named folder using Storage Explorer, rename them back and forth. That moves them from the empty-named folder to its parent folder (i.e. squashes sequences of slashes in the blob name). This changes the blob name, though, so stored copies of the blob name and any code relying on the blob name have to be updated.

I observed the requests and responses using Fiddler. Storage Explorer > Edit > Configure Proxy > Use custom proxy settings (URL: http://127.0.0.1, port: 8888) and run Fiddler. There is also Storage Explorer > Help > Toggle Developer Tools (F12), which displays Chrome developer tools for the app, but the Network tab does not display the requests and I did not want to dig deeper.