Folder excluded in FreeFileSync not excluded in RealTimeSync

[kludovic]

Linux file system. Set up a batch FileSync file to backup all of my personal files to an external hard drive. All hidden files and folders are excluded using /* which works in the FreeFileSync program. However, when attempting to use the batch file with RealTimeSync I get an error message that the app does not have permission to the /.dropbox-dist folder.

[Plerry]

Entries in the FFS Exclude Filter can not, and thus do not exclude those files or folders from being monitored in RTS.
You may be able to define your RTS monitored folders differently, e.g. by defining more folders to be monitored, thereby avoiding that the /.dropbox-dist folder is would be monitored.
You can then still have RTS launch the FFS configuration with said Exclude Filter entry.

[therube]

Entries in the FFS Exclude Filter can not, and thus do not exclude those files or folders from being monitored in RTS.

Huh?
Say that again.

_real has a list of folder pairs
& calls _batch typically
(executes FFS using said _batch, actually)

_batch contains <Exclude>'s...

so why wouldn't the <Excludes> be enforced ?

"enforced"

So the <Exclude>'s are enforced.
OK.

But that does not stop RTS from monitoring any of the <Exclude>'s.

Ah, so that is the differentiating part, "enforced" vs. "monitored".
OK, got it now, thanks.

[Plerry]

RTS "just" monitors the one or more folders specified in RTS (and any of the subfolders thereof) for changes, and upon detecting any such changes will launch its command command line, normally invoking FFS to run a *.ffs_batch sync configuration also specified in the RTS command line.

The feature of dragging a *.ffs_batch configuration into the RTS GUI, that Zenju added to RTS for convenience, just takes all left-right base folder locations from the *.ffs_batch configuration and makes those into its list of folders to be monitored by RTS (or actually the OS) for changes.
And it will specify the correct RTS command-line for invoking FFS to run that *.ffs_batch configuration.
Nothing more and nothing less.

But RTS is blissfully unaware of any further content of the *.ffs_batch configuration that it instructs FFS to open. RTS is therefore also unaware of any entries in the Include and Exclude Filter that may exist in said *.ffs_batch sync configuration.
The same holds if the drag/drop created RTS configuration is manually modified, or if an RTS configuration is fully specified manually.
And that makes perfect sense, because the OS can not be told to monitor one or more folders and their subfolders for changes, but meanwhile to exclude that monitoring for for certain subfolders, files or file-types.

> so why wouldn't the <Excludes> be enforced ?

The Exclude (and Include) Filter entries in the FFS sync configuration do take effect (if you like: are "enforced") within FFS, e.g. when/once launched by RTS.

[kludovic]

Thanks for the help. I just need to restructure my home directory to only have subfolders at the base and then monitor the subfolders I want and not the base directory.

[daveclayton]

I am trying to simply backup usueful files in the USER directory, for all users, to a USB flash drive.
The only problem with not carrying over the exclude filter(s) from FFS to RTS is the number of logfiles created. e.g. If you use *appdata* to exclude any appdata files from the FFS batch file. (because in most cases you don't want them included) You get many logfiles a minute, when an RTS change is triggered because the 'system' has updated something. But there is actually nothing to sync, as far as FFS is concerned. Which is somewhat annoying - I haven't worked out how to avoid this yet??

FYI: I have RTS running as a task triggered at startup, executing an FFS batch with lots of exclude filters. All appears to work great appart from the logfile issue. I use a not normally logged-In account, which is a member of the ADMIN group to run the task and the batch file(s), where the task is considered 'hidden' - thus avoiding the need to change the user to SYSTEM for running as a 'service'. And still keeps everything hidden from normal users.
Happy to be educated : o)
Dave

[Plerry]

For your use-case, using RTS to trigger the start of an FFS sync may not be the way to go, because too many (for you) non-relevant changes will cause an FFS sync to run.
For your use-case, it may be better to not use RTS, but instead run your FFS sync at certain intervals, or at startup, shutdown, logon or logoff, from the Task Scheduler.

Or you need to go to a much finer granularity of the RTS monitored folders.
So, instead of having RTS monitor the [user] folder (which includes the appdata folder), in RTS define multiple relevant subfolders of the [user] folder. Your RTS list of monitored folders does not per se need to be a 1:1 match with the base folder(s) of your FFS sync.

[daveclayton]

Yup that was the conclusion that I was heading to as well.

I think that the finer granularity on RTS monitored folders is out - means it will require an update when any new users are added. I looked into this and it just gets 2 involved and does not easily handle new users.

So not using RTS and using several 'scheduled' FFS runs is probably the way to go.
Just need to ensure that I can get good 'event' coverage to trigger the scheduler...

I think...

Option 1:
1a. Startup - then every 15-30mins
+
1b. Shutdown - Just to get the last update - would be good, but not sure that it will finish before shutdown closes it?

Need to investigate further...

[daveclayton]

Following a quick 'google' it appears that there is no reliable way of doing this with the schedular, though one option is to trigger on event1074. But, how long the task will run for is rather ??? but probably barely a few seconds - just not enough!
I don't want the grief of using gpedit.msc and/or similar.

So will just have to live with Option 1a above. Any update/change gets caught at the next startup. That assumes that there is one. (though I am struggling to think of any practical user situation where this is a problem.