Announcement

Collapse
No announcement yet.

Anybody know why these timestamps differ by up to 30 seconds?

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

  • Anybody know why these timestamps differ by up to 30 seconds?

    Because of the default 3 second tolerance, BC often flags files as different that are in fact identical.

    It's pretty annoying, but it's probably not BC's fault - does anybody know why this happens?

    See the attached screenshot. On the left, the red file (.xlsx) and the one above it (.doc) are in fact identical with the right side versions.

    But the timestamps differ by 25 seconds and 16 seconds respectively. All the other files have identical timestamps (as they should - the files on the left are simply copies of the files on the right, made by ROBOCOPY).

    This is on Windows 10 - the left side is a NTFS volume accessed over the Windows network (SAMBA). The right side is a Google Drive volume (but I think this can happen between NTFS volumes, too).

    Anybody know where these small timestamp differences (< 30 seconds) come from?

    [this is not a FAT16 issue, if that's what you're thinking]
    Attached Files
    Last edited by Dave92F1; 12-Oct-2021, 05:20 PM.

  • #2
    You beat me to it: I thought it was a fat32 issue by your subject line.

    If you load the items on the command line and double check with DIR, do these timestamps match BC4's display? I suspect they are actually different, and you can either increase the timestamp tolerance (default 2 seconds) in the Session Settings, Comparison tab, or enable to run a Content Scan (binary/crc/rules-based) from the Comparison tab to help verify the data.

    If you find files are Binary equal, you can also try to Touch either side, to edit that selected item's timestamp and set it to the value on the other side, to 'fix' them.
    Aaron P Scooter Software

    Comment


    • #3
      I suspect they're actually different, too - that's why I said it's "probably not BC's fault".

      I was just hoping somebody had an explanation of why it's happening.

      Double-checking with DIR is a great idea - I'll try that and report back.

      BTW, I know I can run a Content Scan, but that really slows things down - the (spurious) timestamp difference unfortunately forces me to do that a lot.

      Comment


      • #4
        I don't have much experience with Google Drive, is it possible it's updating metadata in the files, causing the timestamp change?

        You might try comparing a pair of files using Beyond Compare's Hex Compare to see if there are byte differences in the files.
        Chris K Scooter Software

        Comment


        • #5
          Originally posted by Chris View Post
          You might try comparing a pair of files using Beyond Compare's Hex Compare to see if there are byte differences in the files.
          I've done that. In every case the files are binary identical.

          However I'm reluctant to increase the timestamp tolerance to 30 seconds (which would fix this problem), because there may be other files that in fact are not identical which then wouldn't be probably marked as such by BC.

          This is a practical problem - lots of files (maybe 2 or 3% of all files) are marked by BC as different based on the timestamps, but are in fact identical. But the only way to confirm that is to do a (very slow) binary compare.

          Comment


          • #6
            How did DIR report? My suggestion would be to try and 'list' the folder using different connection protocols (drive letter, samba, FTP, whatever you have available) to see if any are better supported or show alternate timestamp data. If one of them is more robust, then it might present expected (closer) timestamps.

            Otherwise, you could configure BC4 to perform the comparison in two passes. The Folder Compare's Session Settings, Comparison tab has an option to enable Content Comparison, but to not run if "Skip if quick tests indicate files are the same". That way, the slower scan only triggers on the (still large?) 2%-3% of the files, instead of the full 100%.
            Aaron P Scooter Software

            Comment


            • #7
              Originally posted by Aaron View Post
              How did DIR report?
              The same as BC4 does. I think the timestamps are really different for some reason I don't understand (not BC4's fault of course!).

              Originally posted by Aaron View Post
              Otherwise, you could configure BC4 to perform the comparison in two passes. The Folder Compare's Session Settings, Comparison tab has an option to enable Content Comparison, but to not run if "Skip if quick tests indicate files are the same". That way, the slower scan only triggers on the (still large?) 2%-3% of the files, instead of the full 100%.
              Tried it, and that really works - probably the best solution for now.

              Is there some way to configure a custom button on the toolbar that toggles that on/off, so I don't have to go into Session>Session Settings...>Comparison each time to change it?

              Comment


              • #8
                Hello,

                Not directly as a toolbar button, but the Compare Contents command works on a selection and is in the right-click or could be a toolbar button. However, this wouldn't enable the "Skip if quick tests" option.

                My suggestion would be to Save A Session with these options enabled. The session then acts like a bookmark for these locations with these settings, and loading it will then re-run the comparison on load.

                Optionally, you could also update the Folder Compare default session settings so that it always behaves this way for any new session, if you want any folder targets to compare this way going forward.
                Aaron P Scooter Software

                Comment


                • #9
                  You cannot do the following inside Beyond Compare, but in Finder (right click on Line with name, size, date etc.) and activate the display of “Creation Date”.

                  Compare manually some of the now TWO dates of the affected files in the Source folder to the Target folder files.

                  In some cases - depending on transfer approach - the Target folder enforces “Modified” dates or “Creation” dates are set to the same value on the destination (often Beyond Compare cannot alter the behaviour). Sometimes it is caused by old drivers/software that no longer works optimally with the target storage platform. At other times it is the WebDAV or FTP protokol configuration on the target platform, where last modified time is replace by creation time or vice versa. In some - seldom - cases only the old FAT12/16 date format is supported (5 bit hour, 6 bit minute, 5 bit seconds - the last five bits cannot keep one second accuracy). I even have experienced cases, where FTP modified dates were strictly enforced by the receiving system (sender could NOT reset to same value as on the source system - in one case it was a legal requirement). Or completely missing (only name and size supported - reason unknown).

                  In your specific example, where 17 seconds end up as 42 seconds, I venture the guess, that the copy program is responsible. If you display both modification and creation dates in Mac Finder for both source and target folders, what results do you get? Just a fictitious example:

                  Left creation time: 17.00.17
                  Left modification time: 17.00.42

                  Right creation time: 17.00.17
                  Right modification time: 17.00.17

                  How long did it take Robocopy to complete the copy on the left from the original on the right? 25 seconds? Is it always the case or intermittently? If you repeat the copy task, will the results on the left side be identical?

                  I’ve seen worse bugs - ahem, sorry - more creative “handling scenarios” where date and time is involved.

                  Especially where different calendars are involved - today day 28, 2021, where I live - like the Thai Buddhist calendar (2564), the Arabic Islamic calendar (day 22, 1443) or the Jewish hebrew calendars (day 24, 5782) were involved - just to name a few examples, that I have had to handle in code ;-) We cannot even agree on the “day off” in this world, so why get upset by mere seconds - Ok, I still see your problem ;-)

                  It may be a case, where the copy program is not able (or expected) to keep date and time consistency (or requires a specific setting to enforce strict time stamp consistencies across the copy process, where it is possible or required).

                  Regards


                  ​​​​​​​

                  Comment


                  • #10
                    I'll throw in my general two cents to double check the Destination device. This can be the hardware, the transfer method used, if there's a file system difference between them, etc, are good places to start.
                    Aaron P Scooter Software

                    Comment

                    Working...
                    X