In Folder Compare, Full Refresh doesn't refresh timestamps

[Zoë]

Perhaps the developers need to look at the code to see what code path is being followed when doing a Full Refresh after changing the rules, compared to what code path is being followed when doing a normal refresh in the same circumstance

I don't want to take over Aaron's troubleshooting, but to answer this specific question: Full Refresh and Refresh both go through the same code path to retrieve directory listings and update last modified times.

We have a global data structure that represents all of the directories and files we know about, and a separate structure that represents the comparison of two directories and and just stores references to those files/folders. In both Refresh and Full Refresh, we retrieve a directory listing and update that first structure in place. The only difference between them is that in Refresh's case, the comparison structure gets notifications for every file that's changed, and in Full Refresh's case the comparison structure is thrown out and rebuilt from scratch. There are some other, irrelevant, differences, but in the end, there's only one copy of each file's last modified time in the system, and there's only one routine that updates that last modified time.

I'd happily look into the code further if there was an obvious place to do so, but there isn't, especially if rules-based comparisons are disabled and if Full Refresh is the failing one.

If I had to guess, a possible culprit could be if you somehow had two directories with identical names (maybe differing only in case) in the same parent directory, or if there were accented characters that were messing thing up. Creating duplicate entries requires bypassing the Windows APIs (e.g., using the Linux subsystem) and the second isn't terribly likely, since BC is conservative in how it handles Unicode filenames, but if you wanted to rule them out, try testing with a new directory structure/share where all of the paths are ASCII characters.

[grindax]

Thanks Zoë. Based on your input, I've re-examined the folder structure.

There are no directories with identical names in the same parent directory. All of the files and folders were created under Windows.

I've run a PowerShell script to recursively scan the entire folder structure and identify any non-ASCII characters. One of the folders (not the one containing the file I'm modifying the timestamp of) contains web links (.url files). A dozen of those .url files contained one or more non-ASCII characters in their filenames. I went ahead and renamed them to delete the non-ASCII characters. There were 7 unique non-ASCII characters in total, across the 12 filenames.

– (en dash)
\x{A0} (no-break space)
»
′
“
”
•

After making these changes to the filenames to ensure that there are no non-ASCII characters anywhere, I've re-run the same test. Unfortunately the bug is still evident and I get the same result as before. After changing the timestamp of the file in both locations and then immediately changing the folder comparison rules, hitting 'Full Refresh' did not update the timestamp on the local (left) side, so the file is shown as being different to the corresponding one on the right. I then hit 'Full Refresh' about another 10 times, with it making no difference. Then, when I hit 'Refresh', the timestamp of the file on the left updated correctly, and therefore all files were shown as being matches.

[Zoë]

If you make other changes to the directory, external to BC, are those picked up? Are size changes? What about if you create a new file or delete one? You said it has nothing to do with OneDrive, but is it only occurring if you make a change to both directories, or does it also affect if only one side or the other is changed? Is it showing up if you compare two local directories? Also, in an earlier post you said "Full Refresh doesn't refresh the timestamp of the file on the right". Is it always the right side of the comparison? What happens if you swap sides?

[Aaron]

In addition to Zoe's questions:
How large are the directories you are comparing?

Earlier, you've been testing with OneDrive folders that are theoretically mostly equal, with Skip content scans if quick tests are equal, so almost all files should be performing a meta-data only scan, with no center column/content scanning between file pairs, correct? And these two computers are directly connected on an internal LAN with a gigabit switch, hardwired? But this mostly meta-data scan is taking an hour to complete? When you look at the file pairs, is there a center column icon population occurring, showing content scan results?

[grindax]

The whole dataset (which starts off identical in every way on both sides at the beginning) is 30GB, made up of just over 8000 files in just over 600 directories. And in the test I'm doing, all I'm changing is the timestamp on a single file, to the same value, on both PCs.

The initial folder comparison I do, using quick tests only, takes just a few seconds. Then I check the 'Compare contents' box so it does a rules-based contents comparison, which takes quite a while, and then when that is finished I uncheck the 'Compare contents' box, click OK, and then hit the Full Refresh button on the toolbar so that it does another comparison using quick tests only, which only takes a few seconds. (This is all already explained in detail in the conversation we've had so far).

Yes, like I've said, both computers, which I explained are under my desk (i.e. they are desktop PCs, not laptops) are connected to the gigabit switch on my desk (not to a wireless access point). Of course, this means wired (Cat 6a, gigabit, wired connections).