I found old corresponding topic, without reply here:
viewtopic.php?t=982
My situation is similar.
I have one FFS_Batch for C:\Folder, excluded C:\Foder\Subfolder,
second FFS_Batch for C:\Folder\Subfolder.
If I want to add RealTimeSync for both paths, first RTS will be triggered even
by changes in C:\Foder\Subfolder, because there is no exclude setting in RTS -
which we don't want to.
So my question is pretty much the same - do you plan to add include/exclude
feature in RTS?
Thank you for your great and active work on FFS&RTS,
looking forward to answer,
Polo
exclude folders in RealTimeSync
- Posts: 21
- Joined: 9 Sep 2011
-
- Site Admin
- Posts: 7280
- Joined: 9 Dec 2007
> I found old corresponding topic, without reply here:
It does have a replay, click on "view all messages"
Right now I see two problems with this request, one about design, the other
about implementation.
The design question is whether the new filter functionality provides enough
useful functionality to be put on the still simplistic RTS GUI. "Enough" in
this context is loosely defined as the product of percentage of RTS users
times functional benefit.
Another design question is how redundant filter information should be managed
between FFS and RTS. As the technical issue shows, this cannot be simply
copied 1:1. It's yet unclear how a feasible approach could look like.
Implementing an exclude filter should be straight-forward. Problems are with
the include filter: Having an include filter other than "*" will usually
require monitoring all subdirectories for changes. In order to maintain
functional correctness, this requires a monitoring restart in case new
directories are created. This is essential for the Linux build, and I expect
this to be required for Windows also, unless I find documentation that states
otherwise.
Problem with restarting is that this opens a small gap in time where changes
could go undetected. Although restarting should be in the range of milli- or
microseconds, this *could* become a problem under hard conditions. I currently
see no way to implement an include filter safely.
Corresponding feature request:
[404, Invalid URL: https://sourceforge.net/tracker/?func=detail&aid=3078636&group_id=234430&atid=1093083]
It does have a replay, click on "view all messages"
Right now I see two problems with this request, one about design, the other
about implementation.
The design question is whether the new filter functionality provides enough
useful functionality to be put on the still simplistic RTS GUI. "Enough" in
this context is loosely defined as the product of percentage of RTS users
times functional benefit.
Another design question is how redundant filter information should be managed
between FFS and RTS. As the technical issue shows, this cannot be simply
copied 1:1. It's yet unclear how a feasible approach could look like.
Implementing an exclude filter should be straight-forward. Problems are with
the include filter: Having an include filter other than "*" will usually
require monitoring all subdirectories for changes. In order to maintain
functional correctness, this requires a monitoring restart in case new
directories are created. This is essential for the Linux build, and I expect
this to be required for Windows also, unless I find documentation that states
otherwise.
Problem with restarting is that this opens a small gap in time where changes
could go undetected. Although restarting should be in the range of milli- or
microseconds, this *could* become a problem under hard conditions. I currently
see no way to implement an include filter safely.
Corresponding feature request:
[404, Invalid URL: https://sourceforge.net/tracker/?func=detail&aid=3078636&group_id=234430&atid=1093083]
- Posts: 21
- Joined: 9 Sep 2011
> It does have a replay, click on "view all messages"
Oh, I forgot to look for that button, sorry.
Now I see these difficulties about it. Exclude filter request is written, so..
I thank you very much for your detailed answer.
Polo
Oh, I forgot to look for that button, sorry.
Now I see these difficulties about it. Exclude filter request is written, so..
I thank you very much for your detailed answer.
Polo
