Azure-storage-azcopy: Downloading an empty ADLS Gen2 folder never ends

[MRayermannMSFT]

Which version of the AzCopy was used?

10.1.2

Which platform are you using? (ex: Windows, Mac, Linux)

Mac and Windows

What command did you run?

./azcopy copy "https://REDACTED.dfs.core.windows.net/REDACTED/New%20Folder/" "/Users/me/Downloads" --overwrite=false --recursive --from-to=BlobFSLocal --check-md5 "FailIfDifferent"

(was using OAuth for auth)

What problem was encountered?

The job never finished.

How can we reproduce the problem in the simplest way?

Create an empty folder in an ADLS Gen2 container and try to download it with a similar command.

Have you found a mitigation/solution?

Check if the folder is empty prior to using AzCopy.

[JohnRusk]

Will add this to our backlog. Can't offer a firm ETA right now, so there's likely to a period of time when you need to use the workaround, I'm sorry.

[MRayermannMSFT]

Sounds good. Thanks John!

[adreed-msft]

I actually just discovered the cause of this incidentally. For some odd reason, we infer this is a blob URL. Not sure why this behavior occurs, but I'll note it on the backlog item.

[adreed-msft]

Uh. Correction, I need to investigate this more.

[adreed-msft]

This one's dead simple. We missed a length check for directories. Container copies do if len(e.Transfers) == 0 and exit if the length is 0. To keep things DRY, I'll move this check to copyDownloadBlobFSEnumerator.dispatchFinalPart.

[adreed-msft]

Though, considering we are about to enter a point where we refactor our copy enumerators, I'll hold off on making this change for now.

[JohnRusk]

TODO: see if we fixed this in the enumeration work. I suspect we did.

[adreed-msft]

Yup, this one is fixed in the enumeration work @JohnRusk. This got fixed due to our changes in STE where a transfer will error out if nothing is scheduled.

[adreed-msft]

This has been fixed in the latest release-- This was caused by us not questioning the number of transfers (both in the FE and in the STE).

Enjoy!