I recall seeing the issue you described (or something similar) while using a previous version of Robocopy.exe (it could have also been on Windows XP rather than my current Windows 7). This behavior was by design, or at least as expected. The issue is caused by the fact that the files and folders (and timestamps) are copied as they are encountered while traveling down the directory tree. For any particular folder, lets call it Folder 'A': • First, folder A is created (and apparently child files if any), and then the Timestamp is set to the same as the Source folder. • If folder A has no child folders, Robocopy continues with the next Sibling of folder A, or back in the Parent of folder A.
Apr 25, 2012 Hello, Earlier today oBdA and QCubed helped me write a batch file to run RoboCopy on my Windows 2003 SBS server. RoboCopy was copying the contents of the M. Robocopy, or “Robust File Copy,” is a command line directory replication tool from Microsoft. Direct3d Driver For Windows 7. It is available as part of Windows 7 and Vista as a standard feature.
The Timestamp for folder A remains correctly set. • If folder A has child folders, they are then created in folder A, which will cause the timestamp of folder A to be modified. The result (if A has Child folders) is, that the first time through, the timestamp for A will be wrong.
The next time through, no new child folders are created, so the Timestamp for A remains correct. As I said, I am currently using Robocopy Version 5.1.10.1027 (XP027), on Windows 7 Home Premium x64. When I try this operation you have described, I find that all the folders (empty or not) have correct timestamps after the first pass, so a second pass is not necessary. Probably, that means that this newer version of Robocopy (XP027) waits until all child files/folders have been completed within a folder before copying the timestamp for that folder.
