I have often thought that I have also encountered what Nudel mentions above. Since reading his post, I have thought some more about this issue, and I finally resolved to do a much more thorough (and painstakingly time consuming) analysis which should provide much more useful information. Ultimately, I resorted to brute-force testing. It is now very clear to me that the real issue is that DST Compensation does not correctly work in both directions. It just so happens that the way I was synchronizing ended up in a certain direction.
@Jon,
Here's my analysis. Please fix this in an upcoming release.
Test Setup
The tests use the following, except where explicitly noted otherwise:[ul][li] Related Directory Opus Preferences or Synchronize options:[ul][li] Show Seconds in time columns – ON[/li]
[li] Preserve the timestamps of copied files – ON[/li]
[li] DST Compensation – ON[/li][/ul][/li][li] Two-way synchronization operation.[/li]
[li] Two instances of the same Test Folder; one instance will be referred to as the Older instance, the other will be referred to as the Newer instance.[/li]
[li] Several files in the Newer instance are one hour to-the-second newer, than the timestamps of their counterparts in the Older instance.
DESIRED RESULTS: These files should never be included in the operation.
[/li]
[li] Several other files are otherwise legitimately different (aside from DST considerations) in each folder instance.
DESIRED RESULTS: These files should always be included in the operation.
[/li]
[li] Three volumes, each with a different file system:[ul][li] A local FAT32 volume[/li]
[li] A local NTFS volume[/li]
[li] A removable UDF Iomega Rev drive[/li][/ul][/li][li] Each volume above contains both an Older and Newer instance of the Test Folder. There are 6 copies total of the Test Folder. Three (3) copies are Older instances—one on each volume type—that are all exactly the same. The other three (3) copies are Newer instances—one on each volume type—that are also all exactly the same. The three Older Instances are different from the three Newer Instances, as described above. This is done so that Older-Newer instances between any two volume types (i.e. Older FAT32 to Newer NTFS, Newer FAT32 to Older NTFS, Older FAT32 to Newer UDF, etc) can be tested and the results of each possible combination verified.[/li][/ul]Test Iterations
Each test iteration should always include one Older instance, and one Newer instance. What should differ with each iteration is which volume (and what File System) these instances are located on. A test iteration is performed for each of the following possibilities:[ol][li] Newer FAT32 to Older FAT32[/li]
[li] Newer FAT32 to Older NTFS[/li]
[li] Newer FAT32 to Older UDF[/li]
[li] Newer NTFS to Older FAT32[/li]
[li] Newer NTFS to Older NTFS[/li]
[li] Newer NTFS to Older UDF[/li]
[li] Newer UDF to Older FAT32[/li]
[li] Newer UDF to Older NTFS[/li]
[li] Newer UDF to Older UDF[/li][/ol]Test Script
The test script below is performed exactly as listed, once for each Test Iteration.[ol][li] Make the Newer instance the Source.[/li]
[li] Turn the Ignore Seconds when comparing timestamps option – OFF[/li]
[li] Click on [Compare].[/li]
[li] Record Expected and Actual Results[/li]
[li] Make the Older Lister the Source.[/li]
[li] Click on [Compare].[/li]
[li] Record Expected and Actual Results[/li]
[li] Turn the Ignore Seconds when comparing timestamps option – ON[/li]
[li] Make the Newer instance the Source.[/li]
[li] Click on [Compare].[/li]
[li] Record Expected and Actual Results[/li]
[li] Make the Older Lister the Source.[/li]
[li] Click on [Compare].[/li]
[li] Record Expected and Actual Results[/li][/ol]Test Results
Yes, I actually went through that 14-step test script 9 different times, and recorded all the results. As a result, I can confirm that the results are identical, regardless of the volume type. Thus, the issue is not with UDF (or any other file system) as I originally thought. However, there is still an issue, but I now have a better idea of where it actually resides. Since all 9 iterations test results were identical, I will only publish one set of results.[ol][li] Make the Newer instance the Source.[/li]
[li] Turn the Ignore Seconds when comparing timestamps option – OFF[/li]
[li] Click on [Compare].[/li]
[li] Record Expected and Actual Results
EXPECTED RESULTS: Only files that do not exist in either location, or whose timestamps differ by more than one hour (to the second) should be included in the operation.[ul][li] Copy from Source (Newer) to Destination (Older): Files 5 Folders 1[/li]
[li] Copy from Destination (Older) to Source (Newer): Files 1 Folders 2[/li][/ul]
ACTUAL RESULTS: Actual Results equal Expected Results. In this case:[ul][li] Copy from Source (Newer) to Destination (Older): Files 5 Folders 1 – correct[/li]
[li] Copy from Destination (Older) to Source (Newer): Files 1 Folders 2 – correct[/li][/ul][/li]
[li] Make the Older Lister the Source.[/li]
[li] Click on [Compare].[/li]
[li] Record Expected and Actual Results
EXPECTED RESULTS: Only files that do not exist in either location, or whose timestamps differ by more than one hour (to the second) should be included in the operation.[ul][li] Copy from Source (Older) to Destination (Newer): Files 1 Folders 2[/li]
[li] Copy from Destination (Newer) to Source (Older): Files 5 Folders 1[/li][/ul]
ACTUAL RESULTS: Actual Results do not equal Expected Results.[ul][li] Copy from Source (Older) to Destination (Newer): Files 1 Folders 2 – correct[/li]
[li] Copy from Destination (Newer) to Source (Older): Files 33 Folders 4 – incorrect[/li][/ul][/li]
[li] Turn the Ignore Seconds when comparing timestamps option – ON[/li]
[li] Make the Newer instance the Source.[/li]
[li] Click on [Compare].[/li]
[li] Record Expected and Actual Results
EXPECTED RESULTS: Only files that do not exist in either location, or whose timestamps differ by more than one hour (to the second) should be included in the operation.[ul][li] Copy from Source (Newer) to Destination (Older): Files 5 Folders 1[/li]
[li] Copy from Destination (Older) to Source (Newer): Files 1 Folders 2[/li][/ul]
ACTUAL RESULTS: Actual Results equal Expected Results. In this case:[ul][li] Copy from Source (Newer) to Destination (Older): Files 5 Folders 1 – correct[/li]
[li] Copy from Destination (Older) to Source (Newer): Files 1 Folders 2 – correct[/li][/ul][/li]
[li] Make the Older Lister the Source.[/li]
[li] Click on [Compare].[/li]
[li] Record Expected and Actual Results
EXPECTED RESULTS: Only files that do not exist in either location, or whose timestamps differ by more than one hour (to the second) should be included in the operation.[ul][li] Copy from Source (Older) to Destination (Newer): Files 1 Folders 2[/li]
[li] Copy from Destination (Newer) to Source (Older): Files 5 Folders 1[/li][/ul]
ACTUAL RESULTS: Actual Results equal Expected Results.[ul][li] Copy from Source (Older) to Destination (Newer): Files 1 Folders 2 – correct[/li]
[li] Copy from Destination (Newer) to Source (Older): Files 5 Folders 1 – correct[/li][/ul][/li][/ol]
Conclusion
I inspected and verified that each file's timestamp to-the-second. I knew which should be included which should not have been included. The number of files and folders to be copied should have been the same for steps number: 4, 7, 11, and 14. All four compare operations should have reported the same numbers of files and folders to be copied. The only variance should have been switching in which direction they should have been copied.
The issue is in DST Compensation, specifically in the logic branch that does not use the Ignore Seconds when comparing timestamps option. More specifically, the issue occurs only when the Source folder contains the file copy that is older by exactly one hour.
One could say: "just turn on Ignore Seconds when comparing timestamps." In my opinion, that is a separate option and should not be related to this issue. The basis for my assertion is that without that option Compare actually works in one direction. Therefore, Compare should work in the reverse direction without that option. Also, I would argue that DST Compensation should work irrespective of Ignore Seconds. If I have a file that is legitimately a few seconds off (not becuase of DST, but becuase of an actual edit), It should overwrite its counterpart, but one that is exactly an hour? No, that is DST. And these two cases need to be handled differently.
