We are pleased to announce the release of AzCopy version 2.5 which can be found here. This version includes several important improvements for performance and usability. We have also created a comprehensive Getting Started tutorial for AzCopy which helps summarizes the syntax for AzCopy as well as guidance for key scenarios. This tutorial can be found here.
AzCopy 2.5 offers these enhancements:
- AzCopy now supports the transfer of an unlimited number of blobs/files. The upper limit on blob/file transfers has been eliminated by keeping the memory usage of AzCopy constant, despite the fact that the number of files being transferred may vary.
- AzCopy now permits the user to supply a SAS token for the destination blob, if the data is being copied within same storage account.
- Previously, it was necessary to specify the command-line option /z to generate a journal file. AzCopy v2.5 will now always generate a journal file, even if the user does not specify option /z.
By default, the journal files are written to the folder
%localAppData%\Microsoft\Azure\AzCopy\. You can use the /z:[journal file folder] option to override the default journal folder. For more details about option /z, type AzCopy /? in the command line window. - The default folder for the AzCopy verbose log is now
%localAppData%\Microsoft\Azure\AzCopy\. - Due to performance considerations, AzCopy no longer supports multiple file patterns in a single command. Users must now issue multiple commands with one file pattern each to address the scenario of multiple file patterns.
- AzCopy now allows users to specify the installation path in the installation wizard.
- AzCopy version 2.5 expands the scope of option /Y, such that this option not only suppresses confirmation prompts when overwriting the destination blobs/files, but also suppresses all other confirmation prompts.
- AzCopy will now alert the user when it is attempting to resolve naming differences between the Blob service and the Windows file system. Some key differences between naming rules for the Blob service and Windows File include:
- The upper limit for the length of a blob name is 1024 characters, as compared to the 260 characters (file absolutely path length) which is often required for backward compatibility with older Windows applications.
- The Blob service allows for a blank blob name, while the Windows file system does not
- Some file names are reserved by the Windows file system, but are permitted for blob names.
- The Blob service supports case-sensitive blob names, while Windows file system does not.
When AzCopy detects naming conflicts when downloading blobs to the Windows file system, it will report the error to the end user.
We recommend that the user name files so as to meet the constraints of both naming schemes, in order to avoid transfer failures. - The command-line option /mov has been removed, as in a limited number of circumstances multiple source files with the same file name could overwrite a single destination file – for example – copying files from storage which uses case sensitive file names to the Windows file system which is case insensitive.
Note that you can always type AzCopy /? for additional details about command-line options and usage.
Windows Azure Storage Team
Would you consider adding an app.config to the project? To use AzCopy in a corporate environment with proxy authentication just these few lines have to be added:
<system.net>
<defaultProxy useDefaultCredentials="true" />
</system.net>
Since there isn't an app.config that isn't possible and other more complicated things like exceptions in proxy/firewall rules must be taken.
Hi Hans,
Thanks for your feedback, we will put this request into our feature list, but no concrete timeline yet.
Zhiming
With the /MOV command line option removed, how can we use Azcopy to move (copy to dest & delete original) blobs from one container to the other. I've got about half a million files in one container, and I need to move them in bunches of, say, 1000 from one container to the other.
Thanks,
__Birm
Hi Birm,
The parameter /Mov has been removed for the reason described in this blog, if you want to remove the original blobs, you may want to try the Azure Powershell or write your own code by various Azure client libraries , if you just want to make sure AzCopy does not copy same blobs twice, you can specify option /XO to exclude the old blobs (comparing between source and destination container).
Please check more details at AzCopy documentation azure.microsoft.com/…/storage-use-azcopy.
Zhiming