In Folder Compare, Full Refresh doesn't refresh timestamps

[grindax]

I've noticed that with a Folder Compare session open, doing a Full Refresh doesn't refresh the timestamps. However, doing a normal Refresh does.

Surely a Full Refresh should do everything a Refresh does, plus more.

In my test I was comparing my OneDrive folder on my local machine (left side) to my OneDrive folder on another machine on my local network (with its UNC path loaded on the right side). I used an external program to 'touch' the modified time of a file in my local OneDrive folder, at which point OneDrive synchronised that touched file to the cloud. I then confirmed in the remote/network destination that OneDrive had re-downloaded the file there and had updated the timestamp correctly. Next, I did a Full Refresh in BC's Folder Compare session that was still open. This immediately recognized the updated timestamp on the local side, but didn't pick up the new timestamp on the remote side. So the files were now seen as different, with different timestamps. I tried a few more Full Refreshes but this didn't change anything. Only when I did a normal Refresh did it pick up the new timestamp on the remote side.

[Aaron]

Hello,

Both a regular Refresh and a Full Refresh should update timestamps, which shows the file's Last Modified timestamp. A Full Refresh is throwing away the current comparison and reloading it, similar to opening a new tab and reloading the base folders.
When you see this happen, if you view the file in Windows Explorer or right-click -> Explorer -> Properties, what timestamp does it show here? And to be certain, a "normal Refresh" is F5, and the Full Refresh is Ctrl+F5

Are you using BC4's OneDrive profile to view the One drive locaiton, or the local folder on your computer? What is your base folder syntax for the Left and Right sides of the Folder Compare?

[grindax]

Windows Explorer directly on the remote PC shows the updated timestamp. And a Windows Explorer window on my local PC that is open to the UNC path of the remote PC also shows the updated timestamp there.

Yes, I'm using F5 for normal refresh and Ctrl+F5 for Full Refresh. I've also repeated the test using the toolbar buttons for Refresh and Full Refresh.

I'm not using any specialized profile. I'm simply doing an ordinary folder compare where the left side is the folder on my local PC (D:\OneDrive) and the right side is the UNC path to the folder on the remote PC (\\ComputerName\Share\OneDrive).

I've tested this over and over again and get the same result every time. It's 100% reproducible. Full Refresh simply doesn't refresh the timestamp of the file on the right. Yet normal Refresh does. It's a bug. Please try it out yourself.

[Aaron]

Hello,

Tested by sharing a OneDrive controlled folder over the network. I duplicated a file and verified the timestamp was preserved while viewing over the network. I then locally updated the timestamp with Touch, then looked on the other machine accessing as \\computer\onedrive\; from the remote location a Full Refresh showed the new timestamps.

What's different about your setup or configuration?

[grindax]

from the remote location a Full Refresh showed the new timestamps.

What does this part mean? I'm running Beyond Compare locally, and therefore all the refreshing I'm doing in Beyond Compare is on my local machine.

It's not clear to me why you can't reproduce this. I can do it easily and consistently. I've provided quite a lot of detail so far. What further information do you require from me?

[Aaron]

Sorry, I probably should have said "pointing to" the remote location.

I have a Folder Compare open pointing at:
c:\OneDrive\Test\ <=> \\remote\OneDrive\Test\

I then went over and sat at the \\remote machine physically, and used its "local" Explorer to create copies of files in the OneDrive controlled folder (its D:\OneDrive\Test\, which would correspond to \\remote\OneDrive\Test\), and touched the timestamps of some files using a copy of BC4 on that machine. This showed immediate results on that machine, showing both the copies preserved the timestamp, and the other files updates went through.

I went back to the original computer running Beyond Compare 4, with the Folder Compare still open, and performed a Full Refresh. This showed both the copies with the original timestamps preserved and the touched files with the new timestamps.

Does this help explain in more detail the steps I took? Do you see different behavior between a Full Refresh and closing the tab and re-opening it?

[grindax]

I've done more testing of this today. When doing a comparison of just a single folder within my OneDrive folder, I couldn't reproduce it. But then when I did a compare of my entire OneDrive folder, with hundreds of folders and thousands of files, I could reproduce it again, just like the other day. So it appears that doing the comparison involving a large number of files and folders may be a key factor.

In my latest test I've done, where I'm now seeing the problem again, let me list the steps in as much detail as I can:

1. I'm doing a folder comparison, with the left side pointing to the root location of my entire OneDrive folder containing thousands of files and hundreds of folders. So on the left I've got: Z:\OneDrive
2. On the right I've got the network location of the root of my entire OneDrive folder on another PC: \\Computername\Users\Username\OneDrive
3. In the Rules, under the quick compare settings I'm comparing file size, timestamps, filename case, and all attributes. I'm also choosing to compare contents (Rules-based), and I've disabled the option 'Skip if quick tests indicate the files are the same'.
4. I've let this compare run, which took about an hour to complete. Afterwards it shows everything as being a match.
5. On my local machine, I've then used an external program (XYplorer) to modify the 'Modified Date' of one of my .xls (Excel 97-2003) files in the local OneDrive folder. This change is then propagated by OneDrive to the network PC successfully.
6. In Beyond Compare, I then hit the Rules button and uncheck the 'Compare contents' checkbox so I don't have to wait another hour for the comparison (I suspect this step may also be a key factor in demonstrating this bug).
7. In Beyond Compare I then hit Full Refresh, and only the timestamp on the left side (i.e. the local side) changes. BC is thus showing the files as being mismatched due to different timestamps.
8. In Beyond Compare I then hit Refresh, and only then is the timestamp on the right refreshed successfully, and the files are shown as being a match.

[Aaron]

Hello,

I followed these steps exactly, and saw a difference in timestamp momentarily (despite OneDrive saying "in sync"), but then a moment later (still using Full Refresh), the timestamp corrected itself. The issue seemed to be OneDrive's synchronization took a little bit to catch up. It might be taking longer for you given a very large OneDrive folder and why you don't see it when working with a small workspace.

If you let it sit for awhile, and try Full Refresh multiple times (without Refresh), does this work out?

[grindax]

Throughout the process I had an Explorer window open to the network location, so I was able to keep an eye on things at all times. During step 5 where I updated the timestamp locally, I immediately checked the timestamp of the file in the network location and I could see that it only took about 3 seconds to update. In other words OneDrive was very quick to update the timestamp of the corresponding file on the remote PC. And it was only at that point, once I knew that the timestamps were the same, that I then moved on to step 6.

Note, also, that at Step 7 I could continue hitting Full Refresh an unlimited number of times (even an hour later) and it would never update the timestamp of the file on the remote side.

[Aaron]

Which OS are both machines running? I've been testing on Windows 10 (all updates applied) with its built-in OneDrive support, using a personal/free OneDrive account.

[grindax]

Same. Windows 10 on both machines and a personal OneDrive account. Since this is just a folder compare, and since OneDrive is only being used to sync a timestamp change, it may be that OneDrive has nothing to do with it.

I'm starting the compare by right-clicking the local folder and choosing 'Select Left Folder for Compare' and then right-clicking the network folder and choosing to compare it to the left folder. So the comparison is starting with one set of rules (the quick compare rules I outlined a couple posts ago). I bet that the key factor is due to changing the rules to to a contents comparison after the initial quick compare, running the content comparison, and then changing the rules back to a quick compare immediately before trying to Full Refresh. And maybe the number of files, or the depth of the folder structure is a factor too.

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.

[Chris]

I followed all 8 steps in your earlier post, including unchecking Compare Contents before Full Refresh, but I haven't been able to duplicate the issue. My test environment used Windows 10 machines and OneDrive personal on both ends, along with BC 4.2.3.

Sometimes antivirus software can introduce odd behavior. Are you using the built-in Windows Defender for anti-virus, or are you using some other antivirus software?

[grindax]

I'm just using the built-in Windows Defender.

[Aaron]

What kind of devices are on your network, and how exactly are the configured and connected? We've been referring to them as local and remote. Are they both Windows 10 machines? Are the OneDrive locations under the same Windows Account control?

If you test outside of OneDrive, does the issue reproduce?

[grindax]

What kind of devices are on your network, and how exactly are the configured and connected?

Both PCs are in the same location (under my desk), connected to the same gigabit switch on my desk.

We've been referring to them as local and remote. Are they both Windows 10 machines? Are the OneDrive locations under the same Windows Account control?

Windows 10 on both machines and a personal OneDrive account

If you test outside of OneDrive, does the issue reproduce?

Yes. It has nothing to do with OneDrive. And in the test I've just run, the side where the Full Refresh hasn't seen the new timestamp is the local side (left).

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.

How are you getting on with this? Also, are you making sure to update the timestamps manually with an external program in your tests, like me, and not BC itself?