Announcement

Collapse
No announcement yet.

18414 Sync not mirroring Date Modified

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 18414 Sync not mirroring Date Modified

    After Sync Mirror to Right, the destination files have the current datetime, not the original datetime:

    http://i.imgur.com/0NtAquw.png

    That's not a mirror. And (unless I change the Settings) it makes the next sync copy all the files again.

    How do I get datetime to be mirrored?

  • #2
    Well, that's strange. Today, without making any session change or even exiting and relaunching the app, the problem is gone:

    http://i.imgur.com/CiidwH8.png

    Comment


    • #3
      What is S:\? As you know, we try to preserve the timestamp during a copy, but if we can't it gets the current timestamp of the time of the transfer. If S:\ is some kind of device that was temporarily preventing this, or has been rebooted or interacted with in any way, it might have restored this ability. At which point, BC's copy is then able to preserve the timestamp.
      Aaron P Scooter Software

      Comment


      • #4
        S:\ is an internal hard drive volume.

        And I would really like to know what could cause BC to fail to read the timestamp from such a device, and without warning too. That's totally unacceptable for my mirrored backups.

        Comment


        • #5
          It's not reading, it's writing. If something on the destination prevents the timestamp setting, then it gets the time of the transfer. This is most common for specialized protocols that aren't fully implemented, like a buggy MTP or restrictive FTP. I'm not familiar with any cases where an internal hdd had similar issues, or that it would clear up without a reboot. If it occurs, please try repeating the test with Windows Explorer to note how it handles the same transfer.
          Aaron P Scooter Software

          Comment


          • #6
            Originally posted by Aaron View Post
            It's not reading, it's writing. If something on the destination prevents the timestamp setting, then it gets the time of the transfer.
            Thanks for the correction. Please pass on my suggestion that a warning be given before writing a fabricated timestamp. Silent loss of data such as timestamp is not acceptable to me.

            Originally posted by Aaron View Post
            I'm not familiar with any cases where an internal hdd had similar issues, or that it would clear up without a reboot.
            Good to know. Thanks.

            Originally posted by Aaron View Post
            If it occurs, please try repeating the test with Windows Explorer to note how it handles the same transfer.
            Will do.

            Comment

            Working...
            X