No announcement yet.

Problem with syncing a mirror session

  • Filter
  • Time
  • Show
Clear All
new posts

  • Problem with syncing a mirror session

    I have a session created in BC3 in which I'm performing a mirror (sync create-empty mirror:lt->rt) based on size and timestamp criterias (criteria timestamp size). I have this running as a weekly scheduled job so I never usually check this, but I recently ran this manually. I noticed that files that haven't changed in years are copying every time. From checking the particular files, it seems that the files have a modified date of 12/31/1969.

    Is there any way I can work around this issue?

  • #2
    You can run the Touch command after you copy files, to touch the source with the timestamp of the destination.

    But first you may want to investigate why those files have those timestamps. Is that side an FTP or network share?

    The issue you are running into sounds like your Source has files dated in 1969, and when you copy to the Destination those files get the new timestamp of when they were created/copied. This timestamp is always newer than 1969, so the copy happens next week as well, since Mirror will copy anything that is not identical.
    Aaron P Scooter Software


    • #3
      Thanks for the reply. I think why the files lack a modified date is pretty much irrelevant at this time, considering that some of these files are 5+ years old.

      I think that running the "touch" command is probably the best solution. For some odd reason, Windows 2003 Server doesn't come with that command so I'll do have to do some searching around to find that utility.


      • #4
        In a Beyond Compare folder session, select the files that you want to touch, then choose touch from the right-click context menu.
        BC v4.0.7 build 19761


        • #5
          I found a command-line touch program that worked on my server and touched the files. I ran the sync operation twice, and on the second run the files did not copy over again, meaning that my issue is now resolved.

          Thanks for that other tip, Michael. At least I'll know a quick way to handle this issue for the future.