I'm currently trying to transfer a bunch of files and folders from one Azure file share to another using AzCopy. I'm running the command: `./azcopy copy 'https://mystorageaccount.file.core.windows.net/files1/*' 'https://mystorageaccount.file.core.windows.net/files2' --recursive --preserve-info=true --preserve-permissions=true` which does a great job of preserving the last modified time for files, but it seems to neglect the creation time for folders. Is there a way to retain those folder creation times with AzCopy? Also, if I were to use Robocopy, would that mean I need to download and re-upload all the files? What's the best approach to transfer a large set of files while keeping as much metadata intact as possible?
4 Answers
Unfortunately, AzCopy does have some limitations when it comes to preserving metadata, especially for Azure Files, since it relies on the FileREST API. If you're looking for a more reliable sync method, Robocopy with data plane access would be a solid choice.
I've definitely faced similar struggles when moving large batches of files. In my case, I had to deal with virtual data rooms, and preserving the folder structure was a real headache. I even created a tool called EZFolders to help manage consistent structures. It’s a different situation than AzCopy, but I’d love to know if anyone has found a reliable way to keep folder creation times intact while using AzCopy versus just relying on Robocopy, which, as you mentioned, has some overhead with downloads.
Another approach could be to run AzCopy first to copy everything over, and then follow it up with Robocopy using the `/e /timfix /dcopy:t` options to fix the timestamps afterwards. It might be a bit of a workaround, but it could save you some hassle in the long run.
Have you tried using `--preserve-smb-info`? That might help with your issue since it’s supposed to handle and preserve more metadata. Just make sure you're on the latest version of AzCopy as sometimes features can change.
That sounds like it could be useful! But I've read that it’s similar to `--preserve-info`, right? I’m not sure if it’ll solve my folder creation time conundrum.
That sounds like a good strategy! I think I’ll try that method, thanks for the tip!