Time of "Last Sync" not updated

[rianno]

With the new updated version 10.5 the last sync's date does not update anymore.

[rianno]

discovered the bug: if it's activated the option "Run a command after synchronization".... and I selected the shutdown, then the "Last sync" doesn't update as you never did any synchronization.

If you deselect this option, then the Last sync date works perfectly.

Please, correct this bug in a coming release.

[rianno]

Still the problem in ver. 10.6 (sic!)
The "last sync date" doesn't update if in "Run a command after synchronization" you select "shutdown"

[rianno]

Still present the problem in ver. 10.7 (sic!)

[Zenju]

Thanks for your report! The issue has been fixed: https://www.mediafire.com/file/iksrrz61ay3rcwd/FreeFileSync_10.8_%5BBeta%5D_Windows_Setup.exe

[rianno]

Thanks a lot. I'll wait for the full 10.8 version (non-beta version)

[jmsxl]

A small quirk still present in v10.8. When two (or more?) configurations are run at the same time, the Last Sync values are not updated. When each config is run by itself Last Sync is updated. See attached screenshot of a just-completed backup. Prior backup was done about a week ago, yet after this new backup, Last Sync shows 38 days for both configs.

[rianno]

Thanks a lot. I'll wait for the full 10.8 version (non-beta version)

Thank you for the updated version

[wcshaff]

Even now with the current version (11.1) the "Last Sync" date is periodically not updated.

[mgabriell]

This bug is still present. So irritating. It's now 2021-03-21, and I'm running the latest version, FreeFileSync 11.8 - 64-Bit - Mar 3, 2021. The last 4 or 5 versions have all had the problem, and random versions prior to that also had the the issue which is what's kept me from purchasing the paid version of FFS. I'll consider buying a paid version when this is permanently fixed.

[xCSxXenon]

FFS doesn't have a paid version, and it seems to be a very random issue. I have yet to see the issue. Run a system log that Zenju may be able to go through and see what is stopping it from working correctly.

[untroll]

I have the same problem even if the option "Run a command after synchronization" is disabled.

[untroll]

Still not work. The problem is when FreeFileSync GUI is open at the same time as a scheduled task is running in background. This causes the issue and this task last sync info will not be updated.

[xCSxXenon]

I don't think there is any way around that as the file holding the details has a lock on it and can only be opened by one process at a time

[Plerry]

The file comprising the last-run information is the GlobalSettings.xml-file (for location see here).
In the referred to FFS manual section it is also stated:
"Note that this file is read once when FreeFileSync starts and saved again on exit. Therefore, you should apply manual changes only while FreeFileSync is not running."
So, a scheduled or RTS initiated FFS batch sync that runs while the/an FFS GUI is open may very well modify the GlobalSettings.xml-file, but, while still open, the FFS GUI is blissfully unaware of any changes (as the FFS GUI instance only reads that file once when the FFS GUI instance starts) and when exiting the FFS GUI instance will overwrite any changes made to GlobalSettings.xml (by other processes/instances) while the FFS GUI was open.
A potential point for improvement, but likely not easy to solve.

[untroll]

It's a really bad design... The file should not stay open all the time... It should be open to get the config at first and when you have to edit something...

[Plerry]

> It's a really bad design...
That's a strong statement.
It is probably fair to say that the choices made did not take into consideration that multiple instances of FFS (under the same user account) may be running at the same time.

> The file should not stay open all the time...
It does not seem to "stay open". The GlobalSettings-file is simply seems to be read at the time an FFS instance opens, and written (including any potential changes by that FFS instance) when that FFS instance is closed (in a regular fashion), without taking into consideration any changes potentially made to said file while that FFS instance was open.

As said: a potential point for improvement, but likely not easy to solve.

[untroll]

Yeah I understand that... but I think it need to be fixed.

At least maybe a workaround can be in place like reading the log directory and check if the date of the latest log file match with the last sync date written in the GlobalSettings.xml. If not then, show use the log date instead of the last sync date and update the GlobalSettings.xml file with that date. It can be as simple as that!

What do you think of my suggestion?

Thank you!

[Elhem Enohpi]

This might be fixed already, but I'm reporting it anyway, maybe it helps:

I'm also seeing "last sync" with inaccurate number of days. I don't have any scheduled tasks or "run command after sync". I just do manual syncs. I have half a dozen configurations for backups that I run each time, about once a month. Opening FFS today, the "last sync" for all the configurations are four or five months old, i.e. haven't been updated the last several times I've done backups. But I'm sure the last time I ran them a month ago, that after finishing the last sync said "today" - maybe somehow that didn't get written out to the GlobalSettings file?

The logs folder shows correct dates, except there are two logs for one of the configurations.

The GlobalSettings.xml lists a bunch of older log files that don't exist anymore, and the "last sync" dates (UNIX timestamps) that are several months out of date. There's also LastRun.ffs_gui that is several months old.

After updating to 11.16 and running the backups today, it seems like they are all updated, and if I quit and relaunch FFS, they still look updated. So maybe it's fixed now.

[mike326]

I'm running 11.17 and get 16:47 that the time I did it before I got a today???

[xCSxXenon]

What