Merge pull request #226909 from normesta/azcopy

Updating with information about MD5 hash

Author: v-dirichards

articles/storage/common/storage-ref-azcopy-sync.md

@@ -4,7 +4,7 @@ description: This article provides reference information for the azcopy sync com
 author: normesta
 ms.service: storage
 ms.topic: reference
-ms.date: 05/26/2022
+ms.date: 02/09/2023
 ms.author: normesta
 ms.subservice: common
 ms.reviewer: zezha-msft
@@ -16,7 +16,7 @@ Replicates the source location to the destination location. This article provide
 
 ## Synopsis
 
-The last modified times are used for comparison. The file is skipped if the last modified time in the destination is more recent. The supported pairs are:
+The last modified times are used for comparison. The file is skipped if the last modified time in the destination is more recent. Alternatively, you can use the `--compare-hash` flag to transfer only files which differ in their MD5 hash. The supported pairs are:
 
 - Local <-> Azure Blob / Azure File (either SAS or OAuth authentication can be used)
 - Azure Blob <-> Azure Blob (Source must include a SAS or is publicly accessible; either SAS or OAuth authentication can be used for destination)
@@ -47,7 +47,7 @@ The built-in lookup table is small but on Unix it's augmented by the local syste
 
 On Windows, MIME types are extracted from the registry.
 
-Also note that sync works off of the last modified times exclusively. So in the case of Azure File <-> Azure File,
+By default sync works off of the last modified times unless you override that default behavior by using the `--compare-hash` flag. So in the case of Azure File <-> Azure File,
 the header field Last-Modified is used instead of x-ms-file-change-time, which means that metadata changes at the source can also trigger a full copy.
 
 ```azcopy

includes/azure-storage-azcopy-sync-guidelines.md

@@ -2,17 +2,17 @@
  author: normesta
  ms.service: storage
  ms.topic: include
- ms.date: 10/03/2022
+ ms.date: 02/09/2023
  ms.author: normesta
 ---
 
- The [sync](../articles/storage/common/storage-ref-azcopy-sync.md) command compares file names and last modified timestamps. Set the `--delete-destination` optional flag to a value of `true` or `prompt` to delete files in the destination directory if those files no longer exist in the source directory.
+ By default, the [sync](../articles/storage/common/storage-ref-azcopy-sync.md) command compares file names and last modified timestamps. You can override that behavior to use MD5 hashes instead of last modified timestamps by using the `--compare-hash` flag. Set the `--delete-destination` optional flag to a value of `true` or `prompt` to delete files in the destination directory if those files no longer exist in the source directory.
 
 - If you set the `--delete-destination` flag to `true`, AzCopy deletes files without providing a prompt. If you want a prompt to appear before AzCopy deletes a file, set the `--delete-destination` flag to `prompt`.
 
 - If you plan to set the `--delete-destination` flag to `prompt` or `false`, consider using the [copy](../articles/storage/common/storage-ref-azcopy-copy.md) command instead of the 
 [sync](../articles/storage/common/storage-ref-azcopy-sync.md) command and set the `--overwrite` parameter to `ifSourceNewer`. The [copy](../articles/storage/common/storage-ref-azcopy-copy.md) command consumes less memory and incurs less billing costs because a copy operation doesn't have to index the source or destination prior to moving files.
 
-- The machine on which you run the sync command should have an accurate system clock because the last modified times are critical in determining whether a file should be transferred. If your system has significant clock skew, avoid modifying files at the destination too close to the time that you plan to run a sync command.
+- If you don't plan to use the `--compare-hash` flag, then the machine on which you run the sync command should have an accurate system clock because the last modified times are critical in determining whether a file should be transferred. If your system has significant clock skew, avoid modifying files at the destination too close to the time that you plan to run a sync command.
 
 - AzCopy uses server-to-server APIs to synchronize data between storage accounts. That means that data is copied directly between storage servers. However, AzCopy does set up and monitor each transfer, and for larger storage accounts (For example, accounts that contain millions of blobs), AzCopy might require a substantial amount of compute resources to accomplish these tasks. Therefore, if you are running AzCopy from Virtual Machine (VM), make sure that the VM has enough cores/memory to handle the load.