Azure Storage Explorer comes with a default URL generator for all files - http(s)://<storage account>.blob.core.windows.net/<container>/<file name>.

The application also allows you to bind a custom URL to the service that takes the place of the "<storage account>.blob.core.windows.net/" section of the URL, making it http(s)://<custom domain>/<container>/<file name>.

It would be super helpful to be able to be able to update the settings to indicate a custom domain is being used so that the "Copy URL" function replaced the root domain for you.

Currently the advice received from MS is to manually replace the indicated URL segment manually, every time Storage Explorer is used to generate a link.

My bad experience says that it's very confusing to present 'Delete container' button (option) on the panel inside the container view.

On attached screenshot you can see the situation.

My user experience here is:
- if any copy/delete/upload/move operations are presented as options (buttons) - they are going to be applied to selected items. NOT a container itself. So my eye is eager to catch any button with garbage can icon and title started with "Delete ..." - to delete selected items
- When I'm in a container view as on screenshot and there are tons of blobs inside this container - last thing I want to do - is to completely wipe out this container.
- I expect to apply any operations against container - when I'm staying one level above it (in parent view) - by selecting it (as a checkbox) or by using context menu
- That's also very sad how easy is to do that and having no any option to roll it back

I would propose to:
- collect statistics how often users use 'Delete container' button for non-empty containers (full of blobs) inside of a container view. I would expect it's not so usual use-case.
- collect statistics how often users do that by accident (changing their mind, clicking cancel, complaining to support that they accidentally removed it)
- if users regularly experience issues because of this behavior - consider to remove this button from this view (redesign this panel)
- otherwise - force user to type a name of the container to make sure this is really what was intended to be done.
- review that design approach for all similar views if there are any

When recently trying to backup our test environment VM's from Azure, we ran into issues exporting VHD's from unmanaged disks, which only allowed us to export and download the VHD using an HTTP URL. The download would fail sometimes only seconds into the download, and other times a half hour or so in, but at 2 MB/second, the TTL on the URL would usually expire before we could re-initiate the download, and due to frequency makes it impractical to use. After working with support, they advised we can move the data from an unmanaged disk to a managed one and then export it, but that would increase our cost temporarily, when our goal is to decrease storage costs as it is. My work-around was to use Firefox with an extension called "Download Auto-Resume", which automatically retries failed downloads without user intervention to overcome our issues.

Import/Export Service: add ability to prepare already copied data to the drive for importing to Azure.

Our application have some data storage, and we do not copy data from disk to disk.
We read data from our storage and want to write it as a stream directly to device, which will be shipped to Azure.

For using WAImportExport tool we must write it on local drive and then copy through this tool. There is a lot of data, so we need additional storage to copy it local. This does not suit us, we want to avoid this.

And of course it takes a lot of time.

So, I think that it'll be good to have ability to prepare already written data on a drive for import job.

Thank you,
Marina

The request is regarding the “storage account” section in Azure. I understand that SMB 3.0 is used to authenticate to the Azure storage container created in the “files” section when it is mapped locally. We have a third-party application configured and running on an Azure VM with Server 2012R2 as the OS, and this drive is mapped to this machine.
We need have another method to allow for the application to connect to this mapped drive as the app requires full UNC paths in-order for it to ingest documents, and this cannot be done without sharing the mapped contents (there is a workaround by creating a symbolic link to the file/folder, but fails authentication). The application does not have an authentication method for SMB requests (no fields for entering username and key) as it runs as a windows service and requires a full UNC path to connect to folder shares for input and output of files.

IListBlobItem contains 6 Uri objects (including contained objects), and then another IListBlobItem for any Parent items that might be available, all the way up to the root.

All 6 of the Uri objects contained in IListBlobItem are basically the same. That is, they might differ if the specify the primary or the secondary storage or something like that.

Since all the Uri:s are made public by get-based properties it should be possible to introduce a base class that implements IListBlobItem and store the information necessary to provide all the different urls as separate components, and then use these base components to build the Uri when necessary.

As it is today an IListBlobItem can easily be way over 1kB, when it actually only needs much less.

Example:
An IListBlobItem representing the blob: https://storageaccountname.blob.core.windows.net/Container/RootDir/SubDir1/SubDir2/BlobName

Will result in 1716 characters in Uri:s within the IListBlobItem, when all that is actually needed is 102 characters, if you split up the different components and build Uri:s on demand when needed.

A list of 100.000 similar blobs would contain 163 MB just for Uri:s. In comparison only 9 MB would be needed for a 100.000 item list if only 102 character was needed.
Imagine what would happen if you did the same for a custom list (not List<blob>), where all blob items shared the info for storage account, container and so on, it would probably bring down the size of the list to half of that (4-5 MB).

As it is today it is requires a lot of manual processing to unpack IListBlobItem to something smaller that is suitable for serialization.