Real Time Sync bugs out while I'm copying files

[njroute22]

OK - I'm having a bit of a bug right now.
I'll give you a simplified example.
I have a main drive with photos. I also have a backup drive for those photos. I employ RTS to update the backup drive each time I add photos to the main drive. Simple, right?

However, I had an issue just now - where I was copying 20GB of files to the main drive - and the RTS started backing up while the copying was still taking place - and spat out some errors (about drive locked, etc.)

Shouldn't the RTS NOT try to back up while my drive is in operation? Doesn't it have to wait for "IDLE TIME?"

Maybe I'm doing something wrong - can anyone determine what might be wrong?

(Oh, and I'm not using the Windows default copy function to move my files - I was using an app called "TeraCopy" if that makes a difference)

[xCSxXenon]

You are correct, RTS waits the 'idle time' before calling the command. It seems that the idle time either isn't high enough or your 'copy to main drive' operation had a pause long enough to outlive the idle time. Either way, RTS should trigger again after the copying is fully finished, allowing FFS to finish the sync. If the .ffs_batch configuration that you are using had 'ignore errors' and 'run minimized' checked, you wouldn't have ever known there was an issue, which could be good or bad depending on your overall backup situation

[njroute22]

If I said "ignore errors" would that be a bad thing? I'm just storing media files (photos, videos, music). Nothing related to national security, etc.

I also saw that I can run as administrator and allow locked files? That is probably the same result right?

[xCSxXenon]

Running as admin and allowing locked files might work, but it isn't the appropriate fix for you. I encounter the same "issue" because sometimes I add or remove data while a sync is running, leading to errors sometimes. I have my setup configured to ignore those errors because RTS will detect the new changes I made and it will start another sync after waiting the idle time again. RTS still detects changes even if a sync is actively running, as far as I can tell. If I were you, I would ignore the errors, but also make sure you have another backup that you run periodically manually, or some other type of restoration method if something goes wrong (versioning, off-site backups, recycle bin, etc.), for the irreplaceable important data. I have never had anything go wrong that was the program's fault, even with conflicts such as the one you are describing.

[Plerry]

> RTS still detects changes even if a sync is actively running, as far as I can tell.

From the RTS Manual page

Limitations: ...
While RealTimeSync is executing the command line, monitoring for changed files is temporarily inactive.

So, if your RTS command-line is set to execute an FFS sync, RTS is suspended during the execution of the FFS sync. I'm pretty sure this applies on a per RTS instance and per FFS sync (launched by that RTS instance) base.

[xCSxXenon]

> RTS still detects changes even if a sync is actively running, as far as I can tell.

From the RTS Manual page

Limitations: ...
While RealTimeSync is executing the command line, monitoring for changed files is temporarily inactive.

So, if your RTS command-line is set to execute an FFS sync, RTS is suspended during the execution of the FFS sync. I'm pretty sure this applies on a per RTS instance and per FFS sync (launched by that RTS instance) base.

So it must be that the sync that occurs while I am still transferring data finishes before my transfer does, thus the detection resumes in time to catch the remaining changes to trigger another sync. So a possible issue would be if the sync gets triggered mid-transfer but doesn't finish before the transfer does, thus never detecting the remaining data transfer as changes. If a directory is used often enough, this is fine because the next change will then catch all that was missed earlier. This issue is so infrequent and I use my directories often enough that this isn't a concern in the slightest, and I would wager that most users wouldn't be any different

[Plerry]

... because the next change will then catch all that was missed earlier. ...

True in essence, but worded a bit imprecise.
After the RTS-launched FFS sync has ended, the next change in the RTS monitored folder(s) will make RTS launch a renewed FFS sync. This renewed FFS sync will then "catch all that was missed earlier".

If there is a risk the described situation could occur more frequently, it may be wise to, next to RTS, have a scheduled task running the same FFS sync. The RTS launched FFS syncs would give an almost instantaneous sync of changes (e.g. during the day), and the scheduled FFS sync (e.g. running during the night) would "catch all that was missed earlier".