Stop RealTimeSync blocking itself when destination folder does not exist by creating it [REQUEST]

[Synchronizator]

Lets assume a user has main drive D and wants to automatically mirror some of its content on backup drive E in real time. So user adds to list of folders to be copied e.g.

D:\documents
D:\music
D:\photos


and then for convenience copies each path and replaces in them

D:\


with for example

E:\backups\


on a path-by-path basis during one quick session of selecting and pasting of copied expression

So what will happen?

Unfortunately nothing- unless user goes to the

E:\backups\


location and manually creates in it folders

documents
music
photos


Because if those folders do not exist then RealTimeSync in Tray changes its red icon to gray on and when hovered upon display info

Waiting until directory is available: "E:\backups\documents"

[and after it being created manually waits also for other non-existing yet locations to be taken care of]


What is the point of setting an automated batch job within FreeFileSync and RealTimeSync and then having to repeat part of the work manually outside of them? Creating [empty or full] copies of dozens of folders is tiresome and / or time consuming

What if a user misses [i.e. inadvertently skips] one folder and then also forgets to check out the color of icon in Tray? User will discover potentially in distant future that backups were not created at all

And what if for whatever reason one of the destination folders on drive E gets deleted or renamed at some point? Is user suppose to constantly manually monitor Tray for changes of icons?

This is just counter productive, dangerous and even illogical, as user is not required to pre-provide every sub-folder within a destination folder


Hence I propose making it possible for RealTimeSync to create destination folders; preferably as a default behavior. And to show a pop-up window warning when it is impossible to create such - which would happen when a whole drive would become inaccessible [so that user would no have to manually monitor Tray icon]

[xCSxXenon]

RTS does not determine what locations are being synced! RTS is only doing the monitoring and triggering. FFS will create folders that don't exist yet, so you need to change the locations in FFS

[Synchronizator]

But I do set the locations in FFS. Thus you could sill argue that a user needs to make first synchronization within FFS and only then start using RTS- which [in my opinion] for a newcomer would not be logical

But

[...]
what if for whatever reason one of the destination folders on drive E gets deleted or renamed at some point? Is user suppose to constantly manually monitor Tray for changes of icons?
[...]

Or to periodically evoke the synchronization by hand in FFS instead of relaying on RTS running automated processes in the background?

[xCSxXenon]

You are correct, any changes in FFS/RTS aren't automatically reflected in the other. I can't think of a good way to achieve that. But, for backup/mirroring purposes specifically, I could suggest that the RTS config [/b]only[/b] monitors the source directories, then the destination set in FFS is irrelevant as RTS won't be looking for it anyway

[Plerry]

> ... and only then start using RTS- which [in my opinion] for a newcomer would not be logical

For newcomers (not necessarily: to newcomers) the present approach makes even more sense than for experienced users.

You first need to "develop" your FFS sync in the FFS GUI, run a Compare, thoroughly review if the proposed sync actions meet your objective (FFS will notify you of any not yet existing left or right base locations, and if you continue with the sync, FFS will create those locations for you).
Then you run the sync and review if the sync-results meet your expectations.
Only if everything is OK, you save the FFS sync configuration as a *.ffs_batch file, and import it into RTS to be run automatically. (By now FFS has created any previously not existing base-locations, so RTS will no longer complain.)
Any other approach means you are gambling with your data.

[Synchronizator]

The way you have presented sure looks logical

But

[...]
Any other approach means you are gambling with your data.

statement is true only if you are comparing / syncing two sets of data both way


I myself have assumed modus operandi with drive D being the main one and the E being a backup one to it- knowing that if data on D gets damaged / removed, so will [with a purposely implemented slight time delay] the mirror backup of it [so that I will have a chance to react if I make some mistake and immediately spot it]. And as I do have other multiple non synchronized backups [i.e. with data/ timestamps] on other media thus my data handling is not dangerous by design. This will be further reinforced by me [planning of] adding another drive to this equation as a RAID 0 to the D drive [to avoid software based glitches and, as we are now discussing, apparent limitations and inner-workings of various backup programs]

The reason I started using program that makes real time backups was to have a ready to use mirror of it in case the main drive dies - and to not have to painstakingly puzzle together pieces of data copied from it to various partial backups on [possibly] multiple drives or optical disks which copies may also vary in the date and time of their creation

And so for me personally drive E not succumbing automatically to changes on drive D equals to a not sound sleep at night and forces me to loose time and energy on trying to make it more sound [by requiring from me manual monitoring and interventions now and in the future]

[Synchronizator]

So what: it is impossible to create / move around / rename / delete sub-folders within monitored folders on main drive [D in my case] and have all of those changes reflected on backup drive [E] - without first going after each such change occurring to FFS and performing manually in it one way synchronization [from D to E] of those already pre-selected monitored folders?

[Plerry]

As long as your changes occur "within RTS monitored folders" and within the FFS left-right base location(s) in the FFS sync configuration invoked by RTS, there is no problem.
(That is, unless your changes would affect your Include and/or Exclude Filter rules.)

However, as soon as you start to make changes outside RTS and FFS to names of RTS monitored folders (as they appear in the RTS GUI) or to FFS left-right base location(s) (as they appear in the FFS GUI) the FFS and/or RTS configuration will not automatically follow your changes.
Therefore, you carefully need to consider the best RTS and FFS setup for your use-case.

(At least in my view) FFS, and to a somewhat lesser extent RTS, are very flexible and versatile programs.
But they obviously have their limitations.
As a user, you may need to adapt your way of working or thinking to the capabilities and limitations of the tools you are using.
If you do that, you will notice you can almost always come to workable solutions.
And that applies not just to freeware solutions like FFS and RTS, but even to very expensive tools.

[Synchronizator]

OK, it is clear to me now how FFS / RTS work in these regards - thank you for your help. I got confused: the last time I stupidly mixed up in my head

[...]
sub-folders within monitored folders
[...]

with just monitored folders during adding of jobs in FFS


All in all what a user has to do is to connect in FFS paths that already exist during setup and should test-run new setup by clicking Compare and / or Synchronize button, before trusting in RTS doing all the work correctly in the background

But still I view my request as something to be considered as possible for implementation - if not by default, then at least as an option