date stamp on log files incorrect

Get help for specific problems
Posts: 3
Joined: 22 Jul 2025

joeejo

I just began testing freefilesync and it looks very promising, however I notice that the date stamp on the log files (that is the date the file was created, not the information within the file), is incorrect.

The log file dates begin with 12/31/2023 and increment from there.

If I delete all the log files, the new ones start being created with the 12/31/2023 date again.

The date and time on my pc are correct.

Any suggestions on why/how this might be happening?

I have attached a screen capture showing the issue.

Thank you
Attachments
Screenshot 2025-07-22 170046.png
Screenshot 2025-07-22 170046.png (52.28 KiB) Viewed 147 times
User avatar
Posts: 2946
Joined: 22 Aug 2012

Plerry

With my FreeFileSync (FFS) v14.3 under Windows 10 the Data Modified is consistent with the log-file title, and the moment the sync finished.
So, is seems to be a specific problem, not a general FFS problem.

What is very remarkable however, is that although your Date Modified date remains at 12/31/2023 (for now?), the time keeps increasing gradually, first from 7:01PM to 7:02 PM, and then from 11:09PM to11:46PM.

No clues as to what may cause this, except for:
You seem to be running your syncs extremely close in time.
Did the previous sync actually end before starting the next sync?
Posts: 3
Joined: 22 Jul 2025

joeejo

Thank you for your reply.

Not sure why it is running so often. It is currently set to back up a google drive (I am testing the program) and I have the delay set to 10 sec but I see no setting to control the frequency. My understanding is that realtimesync will run freefilesync whenever there is a change in the monitored directory, however, the vast majority of the log files state "Nothing to synchronize", so I am unclear why no action is being logged. It seems to be logging with each check regardless of the need to update anything. Is there maybe a setting to prevent logging when no action is necessary that I might have missed?

The time stamp issue I have ultimately found to be a strange anomaly in my router that reset the clock, ignoring the frequent ntp update. The storage drive is connected directly to my router and I neglected to check the router clock when the problem surfaced. By manually resetting the clock that issue appears to have been resolved.
User avatar
Posts: 2946
Joined: 22 Aug 2012

Plerry

I am not proficient regarding Google Drive.
But, form what I understand, Google Drive does not support monitoring your cloud directory for changes using RTS.
See e.g. search.php?keywords=RTS+Google.

It seems to be possible to create a local Google Drive folder, just like you can with OneDrive.
See e.g. https://support.google.com/drive/answer/10838124?hl=en-GB#zippy=%2Clearn-about-drive-for-desktop-benefits.
Then you should be able to use RTS to monitor your local Google Drive folder for changes, and sync that folder to other local or network folders.

Instead of using RTS to launch an FFS sync upon detecting changes, you can also run your FFS sync at regular time-intervals or at specific events (e.g. logon) via the (Windows) Task Scheduler or Apple or Linux equivalent.
Posts: 3
Joined: 22 Jul 2025

joeejo

Yes that is exactly how I have it set up, Google drive is setup as a local directory (not virtual) and that directory is what I am backing up to the USB drive using freefilesync. I am thinking that it is possible that since google is also monitoring that directory, that my somehow be triggering realtimesysc to believe something has changed and, finding nothing, makes the no changes log entry.

Not a big deal, as it appears to be accurately updating files that actually do change on the google directory it is just that it creates a lot of unnecessary log files. I can control how often those are retained so it is not a major issue.

Thank you again for taking the time to address my issue and offer your suggestions and insight.