Can't remove a virtual directory when using a storage emulator

[thisiscmt]

Storage Explorer Version: 1.13.1
Build Number: 20200515.1
Platform/OS: Windows 10
Architecture: x64

Bug Description

I use Azurite on my development workstation to emulate blob storage. I have an app that uploads multiples blobs into various virtual directories. Eveything is inside one top-level virtual directory in a container. Storage Explorer fails to delete that top level directory.

Steps to Reproduce

• Upload a blob into a container and specify a directory path, such as my_dir/level1/level2/some_file.txt (I use the storage SDK for JavaScript)
• Try to delete my_dir (full delete, not a soft delete) from storage explorer

Expected Experience

The some_file.txt blob is deleted and my_dir is no longer shown in the UI

Actual Experience

{
"name": "StorageError",
"message": "The specified blob does not exist.\nRequestId:9ab2902c-81d2-4880-8d8d-b3c99a348e55\nTime:2020-05-27T18:48:32.661Z",
"stack": "StorageError: The specified blob does not exist.\nRequestId:9ab2902c-81d2-4880-8d8d-b3c99a348e55\nTime:2020-05-27T18:48:32.661Z\n at Function.StorageServiceClient._normalizeError (C:\Program Files (x86)\Microsoft Azure Storage Explorer\resources\app\node_modules\azure-storage\lib\common\services\storageserviceclient.js:1205:23)\n at Object.StorageServiceClient._processResponse (C:\Program Files (x86)\Microsoft Azure Storage Explorer\resources\app\node_modules\azure-storage\lib\common\services\storageserviceclient.js:751:50)\n at Request.processResponseCallback [as _callback] (C:\Program Files (x86)\Microsoft Azure Storage Explorer\resources\app\node_modules\azure-storage\lib\common\services\storageserviceclient.js:319:37)\n at Request.self.callback (C:\Program Files (x86)\Microsoft Azure Storage Explorer\resources\app\node_modules\request\request.js:185:22)\n at Request.emit (events.js:182:13)\n at Request. (C:\Program Files (x86)\Microsoft Azure Storage Explorer\resources\app\node_modules\request\request.js:1157:10)\n at Request.emit (events.js:182:13)\n at IncomingMessage. (C:\Program Files (x86)\Microsoft Azure Storage Explorer\resources\app\node_modules\request\request.js:1079:12)\n at Object.onceWrapper (events.js:273:13)\n at IncomingMessage.emit (events.js:187:15)",
"code": "BlobNotFound",
"statusCode": 404,
"requestId": "9ab2902c-81d2-4880-8d8d-b3c99a348e55"
}

Additional Context

azcopy also has an issue with removing a virtual directory using the --recursive flag. If storage explorer is using azcopy under the hood for all delete operations, the bug might actually be in azcopy. See Azure/azure-storage-azcopy#713

[MRayermannMSFT]

@thisiscmt:

• what version of Azurite are you using?
• are any of the blobs deleted, or is every single blob still there?
• could you share the script that does the uploads with us?

[thisiscmt]

I'm running version 3.6.0 of Azurite. And no blobs seem to be removed.

Here is what the upload code looks like, using version 12.1.1 of the storage SDK for JavaScript. I also have NodeJS 12.16.3 on my machine:

public static uploadFileToStorage = async (config: ConfigItem, stream: Readable, fileName: string, storagePath: string) => {
        const blobServiceClient = BlobServiceClient.fromConnectionString(config.azureStorageConnString)
        const containerClient = blobServiceClient.getContainerClient(config.azureBlobStorageExtractionContainer)
        const blockBlobClient = containerClient.getBlockBlobClient(storagePath + '/' + fileName)
        await blockBlobClient.uploadStream(stream)
}

The storagePath param to uploadFileToStorage() could be a single virtual directory name or a path with three dirs like 'dir1/dir2/dir3'. I've attached what the structure of the topmost virtual directory looks like (screen1.png). The top-level one is simply a UUID, then you go down at least two levels before you reach an actual blob, in this case output.log. I would think not having any blobs in the root virtual directory wouldn't matter, it should recursively traverse the entire hierarchy and delete any blob it finds.

[JasonYeMSFT]

@thisiscmt, I can reproduce the issue by simply create a blob with the same name. There might be something wrong with our blob listing logic.