locked
Why does robocopy treat a file as changed after toggling the archive flag and toggling it back again in the destination? RRS feed

  • Question

  • Hi,

    I'm using robocopy to copy a directory to another one (for backup purpose). Now, if I toggle a file's archive flag in the destination, robocopy will identify that file as tweaked when run again (provided that the file didn't change in the source). Ok, all right so far. But if I toggle the archive flag back to its original state and run robocopy once again, it will indicate this file as changed (and copy it again with /copy:dats, /copy:dato), although the file seems to be absolutely identical in the destination and the source. I'm experiencing this behaviour using the following commandline:

    robocopy /V /copyall /MIR 0 1

    This is a problem when a file in the source has its archive flag not set and the /A+:A parameter is specified. If a third party backup software (like a tape backup program) then clears the archive flag in the destination, the file will be copied again due to reason changed.

    What is interesting: with just /copy:dat this file marked as changed is omitted. But when specifying either /copy:dats or /copy:dato the file gets copied (I'm not sure what happens with /copy:datu).

    My host OS is Windows 10 Home 1607, but I'm pretty sure it is the same with Windows Server 2012 R2.

    Any idea why this could be the case?

    I could imagine that changing a file's attributes updates some kind of  hidden timestamp of a file which can not be examined using windows explorer. But then robocopy would have to check this timestamp. However, I can't see any indication for that. I even don't know which timestamp(s) robocopy is using for checking whether a file changed.

    Yours,
    Thomas

    • Moved by jrv Thursday, April 13, 2017 6:23 PM NotmamPowerSHell question
    Thursday, April 13, 2017 10:43 AM

Answers

  • Seems if you are right! If I reset MTime manually after toggling the archive flag and toggling it back again, robocopy identifies the file as same in source and destination (and won't copy it).

    Microsoft seems to call MTime "Change Time" in Win32 API (https://msdn.microsoft.com/de-de/library/windows/desktop/aa364217(v=vs.85).aspx). Considering this it makes sense that robocopy sees the difference in MTime, because it marks the file as "changed" (neither newer nor older), which implies a difference in "Change Time". Of course this is nothing to rely on, there might be other cases where robocopy marks a file as changed.

    Again, Thank You for your help!

    Friday, April 14, 2017 2:27 PM
  • This thread on SuperUser implies there are 8 timestamps on an NTFS file, several of which are "hidden": How can I display all 8 NTFS timestamps? The referenced tool, MftRcrd displays them.

    As a test, I created a file and saved some content into it. When you create a file it has the Archive attribute set. I ran MftRcrd and here is the portion of the output for 4 of the time stamps:

    File Create Time (CTime): 2017-04-13 18:07:13:997:5706
    File Modified Time (ATime): 2017-04-13 18:14:39:295:0571
    MFT Entry modified Time (MTime): 2017-04-13 18:14:39:295:0571
    File Last Access Time (RTime): 2017-04-13 18:14:35:418:2204
    DOS File Permissions: archive

    Then I removed the archive bit (attrib -a) and checked the file again:

    File Create Time (CTime): 2017-04-13 18:07:13:997:5706
    File Modified Time (ATime): 2017-04-13 18:14:39:295:0571
    MFT Entry modified Time (MTime): 2017-04-13 18:14:53:177:5133
    File Last Access Time (RTime): 2017-04-13 18:14:35:418:2204
    DOS File Permissions:

    Note the DOS File Permissions: archive in the first, nothing in the second.

    Also note the MFT Entry modified Time (MTime):

    MFT Entry modified Time (MTime): 2017-04-13 18:14:39:295:0571
    MFT Entry modified Time (MTime): 2017-04-13 18:14:53:177:5133

    None of the other timestamps changed, but MTime did.

    So there is a timestamp that changes when you change the attributes of a file. What I don't know is whether or not Robocopy sees this, though given the behaviour you are experiencing I think it's likely that it does.

    Thursday, April 13, 2017 6:20 PM

All replies

  • This is not a RoboCopy forum.  Post in the form for you version of Windows - "Windows  General Forum"

    \_(ツ)_/

    Thursday, April 13, 2017 6:13 PM
  • This thread on SuperUser implies there are 8 timestamps on an NTFS file, several of which are "hidden": How can I display all 8 NTFS timestamps? The referenced tool, MftRcrd displays them.

    As a test, I created a file and saved some content into it. When you create a file it has the Archive attribute set. I ran MftRcrd and here is the portion of the output for 4 of the time stamps:

    File Create Time (CTime): 2017-04-13 18:07:13:997:5706
    File Modified Time (ATime): 2017-04-13 18:14:39:295:0571
    MFT Entry modified Time (MTime): 2017-04-13 18:14:39:295:0571
    File Last Access Time (RTime): 2017-04-13 18:14:35:418:2204
    DOS File Permissions: archive

    Then I removed the archive bit (attrib -a) and checked the file again:

    File Create Time (CTime): 2017-04-13 18:07:13:997:5706
    File Modified Time (ATime): 2017-04-13 18:14:39:295:0571
    MFT Entry modified Time (MTime): 2017-04-13 18:14:53:177:5133
    File Last Access Time (RTime): 2017-04-13 18:14:35:418:2204
    DOS File Permissions:

    Note the DOS File Permissions: archive in the first, nothing in the second.

    Also note the MFT Entry modified Time (MTime):

    MFT Entry modified Time (MTime): 2017-04-13 18:14:39:295:0571
    MFT Entry modified Time (MTime): 2017-04-13 18:14:53:177:5133

    None of the other timestamps changed, but MTime did.

    So there is a timestamp that changes when you change the attributes of a file. What I don't know is whether or not Robocopy sees this, though given the behaviour you are experiencing I think it's likely that it does.

    Thursday, April 13, 2017 6:20 PM
  • Thank you very much that is a good point to begin with. 
    Friday, April 14, 2017 11:29 AM
  • Seems if you are right! If I reset MTime manually after toggling the archive flag and toggling it back again, robocopy identifies the file as same in source and destination (and won't copy it).

    Microsoft seems to call MTime "Change Time" in Win32 API (https://msdn.microsoft.com/de-de/library/windows/desktop/aa364217(v=vs.85).aspx). Considering this it makes sense that robocopy sees the difference in MTime, because it marks the file as "changed" (neither newer nor older), which implies a difference in "Change Time". Of course this is nothing to rely on, there might be other cases where robocopy marks a file as changed.

    Again, Thank You for your help!

    Friday, April 14, 2017 2:27 PM
  • Thanks, that's a useful resource.
    Monday, April 17, 2017 4:18 PM