none
Robocopy - Destination directories' timestamps are updated even though all files are tagged "same" in robocopy log.

    General discussion

  • Though I have used Robocopy for years to do quick backups and server migrations (both being unidirectional in nature), this is the first time that I have used Robocopy in a bi-directional manner.  

    The task is to bi-directonally sync almost 41,000 files in over 600 directories between the "Master" copy located on a server and the "Remote" copy on a laptop.

    The "Master" data is on a Windows 2008 R2 server, residing on a data (not OS) partition. The "Remote" data is on a Win 7 Pro 64-bit laptop and resides on the OS partition.  Both Master and Remote are NTFS partitions.

    Robocopy is being run on the laptop, where the server-based "Master" data is located via a mapped drive (F:).

    The Robocopy commands in the batch file are as follows:

    1) Initial replication of Master data from server to Remote (laptop):

    Start /Wait Robocopy "F:\Nestedap\ACT!\Document" "C:\ACT!_Data\Nestedap\ACT!\Document" /E /XO /FFT /R:3 /W:10 /NP /V /TS /TEE /LOG+:"C:\ACT!_Data\Nestedap\Robocopy Logs\%RobocopyToDo%.log"

    2) Reverse replication of Laptop data back to Master on server:

    Start /Wait Robocopy "C:\ACT!_Data\Nestedap\ACT!\Document" "F:\Nestedap\ACT!\Document" /E /XO /FFT /R:3 /W:10 /NP /V /TS /TEE /LOG+:"C:\ACT!_Data\Nestedap\Robocopy Logs\%RobocopyToDo%.log"

    Absolutely no changes were made to either the "Master" or the "Remote" data between the two Robocopy passes.  Everything was totally static during testing, so the 'reverse' replication had nothing to do other than to verify that everything matched between source and destination.

    Everything worked as expected EXCEPT, when running the second Robocopy pass (laptop to server) all ** directories ** on the "Master" (destination) had their timestamps modified to reflect the time that Robocopy parsed the destination. 

    Inspecting the log, all the files in any directory one chooses to look at are tagged "same".  Again, both source and target were completely unchanged / static during the testing.  Empty directories did not have their timestamps updated.  This may well be "as designed".  However, having performed exhaustive Internet searches and not having found any reference to such behavior leaves me very concerned that something is happening that shouldn't be happening.  Of course, determining if a "same" file has been erroneously overwritten is nearly impossible because Robocopy (appropriately) replicates all three timestamps (created, modified, accessed) between source and destination.  An indirect indication that "same" files are NOT being overwritten is that the initial pass to populate the Remote took about 15 minutes and the 'reverse' took less than a minute.

    Bottom line, the data involved is business critical and I am very anxious that something untoward may be happening.

    Hopefully someone from the team that developed Robocopy will see this posting and will provide me with a definitive answer!

    ------------

    A side note about my use of the /fft switch in the above:  During initial testing, when all files in both locations were unchanged / static and I had not yet realized that I needed to use the /xo switch, one file (out of almost 41,000 that were unchanged - i.e., exact match between master and remote instances) got copied back to the server.  All three timestamps (created, modified, accessed) on both instances of the file in question were absolutely identical right down to the second and the file sizes were also an exact match.  Unfortunately, I no longer have the Robocopy log file, so I am unable to report how the file was tagged, but I believe it was "Older", with the upper-case "O" indicating that it was copied.  

    In any case, I discovered this MSDN document about file times:  

    https://msdn.microsoft.com/en-us/library/windows/desktop/ms724290%28v=vs.85%29.aspx.  

    Based on that document, I believe that NTFS timestamps may have a resolution more granular than 1 second (perhaps down to 100 nanoseconds).  On the possibility that there may have been a minor glitch in the initial replication pass that caused a sub-second timestamp difference, I added /fft to apply the two-second "tolerance" window, even though neither file system is FAT.  I am not sure if /fft has any effect when both file systems are NTFS and would appreciate any feedback on that point.  Even with the /xo switch, a similar glitch could possibly cause one or more files on the source to be flagged "Newer" and, in that case, erroneously copied back to the destination.

    Thanks in advance, to anyone who attempts to help.

    Thursday, July 16, 2015 5:42 PM

All replies

  • Sorry, but this isn't a robocopy support forum. The participants here are volunteers (not Microsoft employees) who help with scripting questions. I don't think that any Microsoft engineers ever look here, particularly for potential support problems.

    I would recommend that you try to find a general OS forum and post there, and perhaps someone can offer advice. You may need to open an official Microsoft support ticket. (There's no SLA here.)


    -- Bill Stewart [Bill_Stewart]

    Thursday, July 16, 2015 9:11 PM
    Moderator
  • Hello Bill,

    can you tell me please the way to open an official Microsoft support ticket ?

    Thanks very much.


    Friday, May 18, 2018 4:36 PM
  • Friday, May 18, 2018 4:52 PM