[Invalid] [RTS] has stopped, syncing

Get help for specific problems
therube
Posts: 146
Joined: 8 May 2006

Post by therube

[RTS] has stopped, syncing

How to troubleshoot?

XP, FFS 10.11

Syncing from PC to local NAS.

Thought I had a good feel for what was going on, & things were going on just fine.
And then I stepped away a bit.
Came to realize that my last sync was 7-8-20 (per the latest .log file).

Checked & saw that the RTS icon was in the system tray.
But, I was unable to interact with it. Would not open, context-menu failed to display.

Checked & saw that the [RTS] processes were still running.

At that point, figured nothing more I could do except to kill them - which I did.

Fired up the the .ffs_real again.
Shows in system tray, shows as processes, & this time I can interact with it.
Yet it is not doing anything that I can determine (like syncing ;-)).

Associated _gui, _batch, & _real are all unchanged (since 6-24-20).

If I run the _gui, it does see the files needing syncing, as expected.

This is an Update sync.
I'm using UNC paths to the NAS (\\NAS\).
I can, DIR \\NAS\BACK, & get a directory listing as expected (& otherwise interact with it).

I have not restarted my computer.
(Unlike Win10 machines, XP machines rarely need restarts ;-).)

?


Earlier, similar sounding threads:
realfilesync fails after running some time
RealTimeSync only running once
Last edited by therube on 03 Aug 2020, 19:10, edited 1 time in total.
therube
Posts: 146
Joined: 8 May 2006

Post by therube

Rebooted. No Change.

---

Alright, humor me this.
My _real read:
"C:\DEV\BACKUP\FreeFileSync_XP\FreeFileSync.exe" "C:\DEV\BACKUP\FFS_PROFILES\JCS.2.NAS_DB_BU.ffs_batch"
And I think, FreeFileSync.exe ?

And so I run that directly from a C: prompt.

And I see (2) FreeFileSync*.exe fire up (as processes), then disappear.

And I think, FreeFileSync.exe ?

So then I try:
"C:\DEV\BACKUP\FreeFileSync_XP\realtimeSync.exe" "C:\DEV\BACKUP\FFS_PROFILES\JCS.2.NAS_DB_BU.ffs_batch"
And I see (2) RealTimeSync*.exe process fire up.
And then I see the lock files being created in one of the sync'd directories.
And I see a .log file being created.
And I'm syncing :-).

So... what am I missing?
Why had this worked ever since I had a pretty good feel for what was going on.
Only to stop, about a week ago, & with the same, existing _real files (that read FreeFileSync.exe - it didn't work?

Should _real be calling FreeFileSync.exe or RealTimeSync.exe ?

---

When I double-click on JCS.2.NAS_DB_BU.ffs_real, RealTimeSync*.exe (processes) run.
Yet I don't sync?

---

I have another _real that reads:
C:\DEV\BACKUP\FreeFileSync_XP\FreeFileSync.exe" "C:\DEV\BACKUP\FFS_PROFILES\LIB.2.NAS.ffs_batch
And that one does sync. (Happened to be nothing to sync, so it just created a .log)

---
Yet I don't sync?
Actually, it did, just now, quite a bit of time - after the fact.
So maybe it was "busy" & hadn't met the threshold?

That, I can kind of understand.

But what happened between last week, through yesterday, & initially this morning?

---

.ffs_real looks to be associated properly.
---> "C:\DEV\BACKUP\FreeFileSync_XP\RealTimeSync.exe" "%1"
User avatar
Plerry
Posts: 1027
Joined: 22 Aug 2012

Post by Plerry

Your 2nd post was not very clear in which commands are used where.
For launching a RealTimeSync (RTS) instance via command line, you obviously need to use "realtimeSync.exe", prepended by its proper path, and specifying the proper *.ffs_real RTS configuration. Alternatively you may launch RTS by double-clicking a *.ffs_real file, provided the proper file association is defined (which apparently is the case) .
If you want RTS, upon receiving a notification of change(s) in the monitored folder(s), to launch FreeFileSync (FFS), you need to specify a command line within RTS of "FreeFileSync.exe", prepended by its proper path, and specifying the proper *.ffs_batch FFS configuration.

Why your running RTS instances seemed to have become unresponsive I don't know.

You mention that after killing the unresponsive RTS instances and restarting RTS, (still) no sync was run, while when manually starting FFS, it showed files to be synced. Depending on when these changes in the monitored folder occurred, that may still be correct behavior. RTS will only launch FFS if it is notified (by the OS) of changes in the monitored folder(s) while RTS is active (and responsive ...), not if those changes occurred while RTS was not active (and likely also not when RTS was unresponsive ...).
Also note that, if there is a lot of activity (anywhere) in the folder(s) being monitored by RTS, it may take a long time before RTS will launch FFS, particularly if you have defined a long idle-time in RTS.
Therefore, you should preferably minimize the scope of the RTS monitored folders (only monitor what really needs to be monitored, not more than that) and should not set the idle-time too long.
therube
Posts: 146
Joined: 8 May 2006

Post by therube

So... it's been a week.

And all had been fine...

RealTimeSync.exe & RealTimeSync_XP.exe are both "running".
Neither appear to be using any resources, no CPU, no I/O.

Icon is in the System Tray.
Mouse-over shows that it is RTS, but there is no right-click context menu, nor does double click open it.

Last log it generated was 07/28/2020 11:33:11 AM.

After that time...

I had manually run 3 other .ffs_gui.
LIB.2.NAS 2020-07-28 121136.087.log
NEIL_OFFICE (aka stevenhd) 2020-07-28 121340.723.log
RUBEN_C_to_NAS 2020-07-28 121807.949.log

At this point, I'm thinking ? that it was the fact that I manually opened FFS & for whatever reason that is interfering with my RTS?

Some of the directory pairs between RUBEN_C_to_NAS.ffs_gui do overlap the RTS instance, JCS.2.NAS_DB_BU.ffs_real. Maybe that's it?

No odd .ffs* on my HDD (only _gui, _batch, & _real).
No odd .ffs* on my NAS (IOW, nothing odd has been left behind, there).


Kill, RealTimeSync.exe & RealTimeSync_XP.exe.
Both gone, tray icon gone.


Fire up, JCS.2.NAS_DB_BU.ffs_real.
Tray icon shows up.
Context menu there as expected.
Minimal I/O blips from RealTimeSync_XP.exe as expected.

So it looks like it is working (again).
Let's see if I get a log...
JCS.2.NAS_DB_BU 2020-07-29 122253.123.log

And while this was going on, opened FFS & ran
LIB.2.NAS.ffs_gui & JCS.2.NAS_DB_BU.ffs_gui,
then quit FFS.

And RTS is still running (including context-menu displaying...).
So my theory about overlapping scans of same data area might be a bust.


Guess I just have to keep an eye on things...


Current.
FreeFileSync RTS showing activity minimal as it is.png
While there is only minimal CPU, I/O, normally, when RTS dies, there is none.
You do not have the required permissions to view the files attached to this post.
therube
Posts: 146
Joined: 8 May 2006

Post by therube

Isn't it great when you can come across a "bug" & then come back in & say, hey, it isn't really a bug.

So...

As I'm always working from behind, never caught up, it's not unusual that I need to set my computer clock, BACK, to some time in the past.

When I do, I'll typically use, Beyondo (Free Utility To Change Your Desktop's Date). Convenient. Set a date, do what you've got to do, then when done, Reset, & all is back to current. Done.

Except.

Except that when RTS is running, that backdating throws RTS for a loop, where it simply, stops (reacting).

So, now that I know, easy enough to mitigate :-).


(Using the 'System Clock' or DATE from a C: prompt works equally as well [to break things].
Going forward in time is not an issue.)