Refresh - seems to do nothing(?)

[bcdewul]

Folder compare - refresh: It strikes me that refreshing doesn't do anything from times to times. My workaround so far is then to reload the folder compare from scratch.

It says 'Fast Refresh'.
Fast.. ? What is the difference towards a 'normal' (Windows Explorer) refresh?

Example - just now I compared folders, opened a folder with "Open With >" , updated the time stamp of a file, returned to Beyond Compare, refresh, nothing changed. time stamp still the previous one.
Looked for a way to, let's say, "Reload" the existing compare (when it is still open), instead Fast Refresh.

BC 4.3.2 24472 (Nov.1 2019)
I did not see any point in updating as over 2/3 of the last 5 updates involve Mac anyhow.


later...
Beyond Compare > Exit
Relaunch
Selected the folders again, checked, timestamp still didn't change within Beyond Compare, still showing the below.
All difference 1 hour, why is that BC shows 1 hour plus?

[Aaron]

Hello,

A Refresh will look for changes in the listing and then update them, while a Full Refresh will fully reload the comparison in place like you are looking for. Both commands are in the Edit menu, or can be added to the Toolbar in the Preferences, Toolbars/Etc tab, Select View: Folder Compare.

I'd suggest updating to the latest BC 4.x release. All 4.x updates are free for 4.x users and contain a variety of fixes which may intentionally or unintentionally impact or fix this behavior.

[bcdewul]

Thanks. Updated. Regretfully it made no difference though. Is there any reason why BC is one hour off as far as displaying the modified times, i.e. always 1 hour later ?
(see above screenshot)

[Aaron]

Hello,

Could you clarify: is the current issue a timestamp display issue or a refresh not pulling in any changes issue? These would require different troubleshooting steps.

If you fully close BC4 and open it again, is the timestamp changed and now the correct timestamp? Or is it always one hour different?

What base folders do you have loaded? Is one of them an FTP or other type of remote location?

[bcdewul]

Refreshing or exiting and relaunching does not make a difference. I did some other checking and noticed it occurs with images (with EXIF) only.

See attachment.

When I run BC on (e.g. PDF folders, then the modified date does not show a difference.
Note that I always add the modified (or in case of photos) the EXIF date taken to the file name.
(Reason is a long story).

[Aaron]

Hello,

What process do you use to modify the EXIF date taken on the file, and does this process also update the Last Modified timestamp in Windows Explorer when you perform it?

If you launch the Windows Command Prompt, navigate to your directory, and use "dir", what timestamp is displayed on the command line for the problem file?

Are both sides of your comparison NTFS, or is either side Fat32 or exFAT or another file system? What base folder syntax are you loading exactly?

When something is exactly an hour off, the most common cause is a difference in file systems and daylight savings, but it is odd to see it between only Picture/Exif files. I wonder if Explorer is pulling in any Exif information, while BC4 is strictly using the Last Modified field. BC4's Picture Compare can display and compare the EXIF, but it wouldn't be used for the Folder Compare's Modified timestamp.

[bcdewul]

Hello,

Thank you so far.
I am sorry, but I think I let it rest, no offence meant.

It is just an unexplainable thing for me.
As far as I can see it only involves digital photos. Scans or screenshots (or other types of documents) don't have this issue.
Also I discovered that sometimes for other files (photos), within the same folder and shot with the same camera, but on a different days, the modified dates are correct. I checked summertime/wintertime but that is a matter in this case.
Beyond compare adds an hour to the 'Explorer' modified date, being the same as EXIF. For me there is nothing I can do about it.

I let it rest now, this is costing too much time for the both of us.
Again, no offence meant.

Best regards.

[Zoë]

This is an issue with how Beyond Compare handles timestamps internally. When we get the timestamp from the filesystem/FTP site/archive, it may be in UTC, and we convert it to the local timezone. Right now BC uses the same hour shift for all timestamps, while Explorer uses the shift that was active at the time of the timestamp. It means that the timestamps displayed in BC will shift by an hour when you're on one side of the daylight saving boundary or the other. It's been this way since BC1, since early on Windows didn't have a way for us to do the correct shift. It is possible to fix it now, and we would very much like to, but doing so is tricky and touches a ton of areas, so it's been deferred so far. Our recommendation in the meantime is to use the "Ignore daylight saving difference" option in the Folder Compare Session Settings.

[crwdfwtx]

WRT the original poster's question, I came here looking for an answer as well. On macOS with latest BC for a large folder compare, the "Fast Refresh" on a particular folder often does not seem to respond. I can launch a full refresh but that somewhat defeats the point since it takes at least five minutes to refresh the full set of folders, which are on a shared network volume.

One issue that seems relevant is with my large folder compare loaded, after performing an operation such as "Mirror" on a given folder, or even deleting a folder on one side or the other, the app displays a perpetual "wait" pointer cursor, basically the blue beachball with an arrow. For the rest of the BC session, the mouse shows that wait cursor, even if I do a full refresh.

Another interesting aspect here is that often I am not actually using BC to merge my files from one side to the other. My main task is merging two large music libraries, so I will typically add my music files on the left side direction to Apple Music, which then places them in the right side folder as it loads the files in the Music app. But when I go back over to BC to that right side folder that has been updated, the compare app does not see the new files or folders until I do a full refresh.

It has been a while since I used BC intensely so I'm not sure if/when this new issue would have arisen, but it's a bit of a pain to have to reload the whole folder compare, missing out on what was clearly the intention of Fast Refresh to reload only the desired portion of the folder structure.

Hopefully this will ring a bell with someone, thanks.

RW
Dallas, TX

[Aaron]

Hello,

This issue is unrelated to the original thread, but given the title I can see why you found and posted here.

When issuing a Refresh (toolbar or Edit menu), this should work to pick up changes but usually happens so quickly as to not seem obvious. You can test this in a simple scenario, with a single folder loaded on one side. Rename or copy a new item into the folder and trigger a Refresh. I assume this works correctly and without the beachball issue? We can then troubleshoot the difference between this simple/working setup and your more intensive workflow.

When encountering the beachball during your more intense setup, what base folders have you loaded? Are they local /folder/locations/? External devices? Or is either side a network or remote location?

When seeing the beachball is the Stop/cancel button in the toolbar greyed out or blinking? Do all files and folders appear to have sizes calculated (minus top level Orphan folders, which aren't scanned by default)?

[crwdfwtx]

I tried your simple use case on local folders and the behavior is just as expected. A Fast Refresh picks up the changes without needing to go back to full reload.

As for my setup it's pretty extreme. I'm comparing two relatively slow network drives with very large directory structures (about 600 top level folders and ultimately about 60K files to compare). It's a stress test for sure, and I expect performance to be pretty slow. What has been confusing is the app never seems to do a refresh at all, regardless of speed.

The factor I probably haven't been paying enough attention to is whether the Stop/Cancel button is blinking at the moment, indicating there's already an operation underway. I can't quite say about all the calculated sizes, etc. but in general the folders appear "solid" rather than "outline" in appearance which I have taken as a cue that BC has already evaluated that folder. But that may not be a good assumption during fast refresh vs full.

I plan to be a little more aware of the Stop/Cancel button before I lost patience with fast refresh on an individual folder, maybe that's all that's going on.

Sorry for highjacking the OP's topic. If I need further assistance, I'll create a new post. Thanks for the information!

RW
Dallas, TX

[Aaron]

That's perfectly fine. I replied here because of how searching led you here, and assume other users would stumble into this thread as well (and may get answers once we have them). I just wanted to clarify the issues weren't related before continuing the thread.

It seems like everything you are doing is what I'd recommend during troubleshooting. You are watching for the right things and that is a larger comparison, though not extraordinarily large. Are any of the sides external or remote devices? That could be a further bottleneck that is slowing down the response of the (quick) Refresh.

[crwdfwtx]

Both sides of my folder compare are external volumes that I share over my network (an up to date Synology NAS with brand new 7200rpm drives and a perky 802.11ac wireless). My client machine is a base model brand new M1 Mac Mini (Wi-Fi not wired). I have an entirely separate head scratcher going on where access times to that NAS are crazy slow over the network but that is not at all unique to BC (which by the way is latest 64 bit version of the app running under the Monterey macOS public beta).

RW
DFWTX

[Aaron]

Hmm,

Thanks for all that info.

For the NAS devices, what is the base folder syntax loaded? Would you be connecting with smb://nasname/folder or was the device already mounted and connecting with a different syntax?

As a test, it might help to compare from a SourceNAS to a LocalTemp folder, and from LocalTemp to DestinationNAS, to see if it is an issue with either side (only reproduces in one scenario and not the other), or with NAS to NAS only. It's also possible the more complex data set, if Local to Local, might cause the issue, but we can test a few other things before trying to recreate that. It's much more likely an issue specific to the NAS devices. As one troubleshooting step, are they running the latest firmware and have they both been fully power cycled down and rebooted?

[crwdfwtx]

Hello, sorry for the response lag. I do use smb protocol to connect to the drives and have done what I can to optimize Synology's Samba support options.

As for local vs remote testing let me see what I can do. There are nearly 2TB of data files in question here so testing locally isn't always an option, but I can probably come close to reproducing this scenario.

The NAS is running very latest firmware and I just replaced both hard drives with 7200RPM Seagate drives made especially for NAS, which involved a lot of power cycling and that was a couple of weeks ago. Performance since then has improved perceptibly but is still quite slow over wifi.

Related note, my big project to reconcile my two large library folders is done now so the heat on this is somewhat lesser now. I do need to follow up and reconcile my "current" and "archive" folder structures though, so I'll be back to relying on BC hot and heavy pretty soon.