I normally use the built-in file copying program into Windows when I backup my data disks. Then I started to use TeraCopy which was great but then I wanted to take things to the next level. Why? Because who doesn't like to complicate things?
I copied all my data from my data disk using robocopy and I found that all the folders only, now have the date of the "time of copy" rather than the original date. I used the following command-
robocopy E: "F:RAID_BACKUP" /E /Z /MIR /MT:64 /R:3 /W:1 /LOG:"RAID_Backup_1.txt"
After doing some searching online, I found this helpful article on how to preserve the date and timestamps:
timestamp - What switches can robocopy use to preserve file and directory times on the target? - Server Fault
So it looks like I forgot the /COPYT /DCOPY:T which I thought would be automatic.
Anyhow, moving forward, when copying within Windows or even TeraCopy, what is the equivalent in Robocopy to a "cut and paste" or a "drag and drop copy" or even a "drag and drop move" within Windows? I dont ever want to make this mistake again and maybe I should have just left the command line to the pros
I use robocopy and use these switches which works well for me /e /mir /np /tee /log:backup_log.txt
see if this is something that may help although it is not the command line in robocopy 'Copy To folder' and 'Move To folder' Context Menu - Add in Windows 10
Thanks for sharing your command and switches.
So when you use that, does it also copy the original folders creation date? The only difference between your switches and mine are the ability to see the output (/np /tee) and multi-thread (/MT), restart mode (/Z), retries (/R:3), and the wait between retires (/W:1).
I don't see how your switches preserve the original date of folders but mine would not.
Mine do unless one is changed. When the contents of the folders change, it uses the newest date. I have always been under the impression that the z switch was only useful with a NAS, in case you lost connection. I do use the MT switch but left it out as most people wouldn't need it. The default, I believe is 8, so you would only need it to use more, which mine never does anyway, but I use MT:10.
Interesting.
I will have to do some more testing.
I wonder if the /MIR is actually whats messing everything up? In theory, if its a new copy then it would need a new directory, thus the new timestamp. But if its the first copy ever, you wouldn't think that would happen.
I ran it last night, but here are a few of my folders.
So then it appears the timestamps on the folders changed, which makes sense, only because there was new content/updated content placed inside. But if you ran the copy for the first time, you wouldn't think this would happen. That is what I'm trying to figure out. If you copy contents from X to Y and Y has never had the contents copied to it, shouldn't the directory's created timestamp be applied to Y's destination?
Perhaps these switches are needed then?Code:/COPY:DAT /DCOPY:T
There seems to be a little chatter about this on the man page for it, if you scroll down just a bit. Search for "Copying of directory time stamps issue"
https://technet.microsoft.com/en-us/library/cc733145(v=ws.10).aspx
My folders seem to carry the date of the most recent file inside that was updated. Opening the folder, all the files seem to carry their original date. The new files carry the date they were created, and thus change the folder date.