Azure-storage-azcopy: --overwrite=ifSourceNewer and --preserve-smb-info=TRUE cannot be used at the same time. WHY?

[Dikkekip]

Which version of the AzCopy was used?

10.10.0

Note: The version is visible when running AzCopy without any argument

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

Windows

What command did you run?

azcopy.exe cp
"C:\azcopy\log" "https://.....file.core.windows.net/root?sas"
--recursive=TRUE --check-length=TRUE
--overwrite=ifSourceNewer --log-level=WARNING
--preserve-smb-info=TRUE --preserve-smb-permissions=FALSE
--output-type=text

failed to parse user input due to error: preserve-smb-info is set, but it is not currently supported when overwrite mode is IfSourceNewer

Note: Please remove the SAS to avoid exposing your credentials. If you cannot remember the exact command, please retrieve it from the beginning of the log file.

What problem was encountered?

failed to parse user input due to error: preserve-smb-info is set, but it is not currently supported when overwrite mode is IfSourceNewer

We are Copying files from a local file server to Azure Files. We of course want to keep the SMB info since it contains: last write time, creation time, attribute bits
However we do not want to copy all files again (around 8 TB of data and a lot of tiny files).
This seems to be impossible in AzCopy.

Could you please answer the following questions.

1. If we do not have the Metadata in the (azure files) destination. how can AzCopy determine the ifSourceNewer flag to be accurate?
2. Is there any way of getting both the SMB metadata and only the newer files into Azure Files

We cannot use azcopy sync since we need to copy empty folders as well. :-(

How can we reproduce the problem in the simplest way?

Copy a local path to azure files with the flags provided.

Have you found a mitigation/solution?

No not yet.

[njalwogn]

Interesting. Would be good to have som feedback on this.

[nakulkar-msft]

Overwrite IfSourceNewer works by comparing timestamps of the source and destination. On a filestore, the timestamp is not changed when metadata or acls are changed. So azcopy would not be able to tell that the smb-info for a particular file has to be captured again. We're working on resolving this.

[njalwogn]

so this behavior is not spesific to any version of Azcopy?

[njalwogn]

What would be your suggested way of preserving created and modified date, and do delta copying from local filesystem to Azure Files?

[Dikkekip]

@nakulkar-msft
The problem is now that we have 300 000 new files without SMB metadata.
and the full run / alternative, takes 26 Hrs to complete, that is too long for us, within the window we have during the cutover to azure files.
We could use --include-after flag to reduce the time spent and manually create full and incremental runs.
But that would mean that any locked / failed files with a time stamp older then what we define in the include-after tag.
Will not be copied due to there time stamp and can potently mean there is data loss within the process.

Any ETA on this potential fix?