Hello!
I want to sync a bunch of configuration files that are stored directly under my Windows %USERPROFILE% (.gitconfig, .bashrc etc.). User profile will constantly trigger a bunch of filesystem events unrelated to the files I want to sync. These changes will result in either:
- Not being able to sync when idle time is high.
- Constantly running sync when idle time is low.
Is there any way to configure RealTimeSync so that it ignores unrelated changes? And if not would that be possible to add option to ignore events from subdirectories? I'm not sure which mechanism is used for monitoring, but in case of .NET FileSystemWatcher it is quite straightforward to do that (wanted to link but only got called a spammer by the server and had to write the post again...).
For now I excluded user profile from monitoring and have to live with just one way sync.
Any help appreciated :)
RealTimeSync huge directoriy with only a few files to sync
- Posts: 1
- Joined: 21 Mar 2020
-
- Posts: 2280
- Joined: 22 Aug 2012
Apparently you have set the scope of your monitored folders undesirably wide.
You can try limiting the scope of the folders monitored by your RTS instance,
and/or divide your monitored folders in smaller groups, each monitored by a separate RTS instance; each RTS instance launching a separate FFS sync, each such FFS sync having a scope matching the limited scope of the RTS instance launching FFS.
You can try limiting the scope of the folders monitored by your RTS instance,
and/or divide your monitored folders in smaller groups, each monitored by a separate RTS instance; each RTS instance launching a separate FFS sync, each such FFS sync having a scope matching the limited scope of the RTS instance launching FFS.
- Posts: 5
- Joined: 24 Mar 2020
Hello. I now have come accross a need to address this
This topic seems to bob up regularly, and in my estimation it comes from two factors.
1. RTS seems (to me) limited to folder level monitoring, and
2. FFS seems (to me) limited to folder level compare (with filters) and sync when run as a hidden task.
(probably an over simplification but that how i see it.)
So the questions then I ask are
- What information does RTS receive from the OS when its informed that a change has taken place?
- Can RTS be developed to (a) have a filter function like ffs - this may help the OP in that only specific files trigger RTS to call FFS, and (b) receive granular information from the OS such as which specific files the changes relate to (regardless of filter)? It would have to log them all until the idle time function is satisfied and it calls FFS, upon which it would pass that information on to the FFS batch file, or other program and then empty the log ready for the next round of monitoring.
- Can FFS be developed to take this info and dynamically "adjust" the filter for that batch and only compare/sync the relevent files?
Would this speed things up?
The example i have is that i have 3 salesmen who each have a folder for the current financial year. In those folders, they create a new folder for each quote, where all the info for that quote/job gets kept.
Since they get multiple new enquireys each day, or enquireys are revised multiple times over days, or even months, it is impractical to set up a new RTS and corresponding FFSbatch for each quote file. So it ends up that the entire financial year gets locked while one person saves a change, and two or even three others (working on different quotes for that same salesman) get error messages if they happen to save even a simple item. The alternative with scheduled FFS batches has the same issue, just on a scheduled basis.
Lastly, this then ties into where FFS puts the "sync.ffs.lock" files. because if it still puts it at the top of the folder, then same problem (but it wont last as long because only a limit number of files will be compared/synced). Perhaps a new type of lock file can be used (sync.ffs.zaplock) to only lock either the specific folder in which the specific file is, or even just lock that specific file for editing by FFS.
Anyway, thanks for reading my ideas. Great product. Not knowing much about coding and software development, i can only hope that these might be viable ideas for implementation.
This topic seems to bob up regularly, and in my estimation it comes from two factors.
1. RTS seems (to me) limited to folder level monitoring, and
2. FFS seems (to me) limited to folder level compare (with filters) and sync when run as a hidden task.
(probably an over simplification but that how i see it.)
So the questions then I ask are
- What information does RTS receive from the OS when its informed that a change has taken place?
- Can RTS be developed to (a) have a filter function like ffs - this may help the OP in that only specific files trigger RTS to call FFS, and (b) receive granular information from the OS such as which specific files the changes relate to (regardless of filter)? It would have to log them all until the idle time function is satisfied and it calls FFS, upon which it would pass that information on to the FFS batch file, or other program and then empty the log ready for the next round of monitoring.
- Can FFS be developed to take this info and dynamically "adjust" the filter for that batch and only compare/sync the relevent files?
Would this speed things up?
The example i have is that i have 3 salesmen who each have a folder for the current financial year. In those folders, they create a new folder for each quote, where all the info for that quote/job gets kept.
Since they get multiple new enquireys each day, or enquireys are revised multiple times over days, or even months, it is impractical to set up a new RTS and corresponding FFSbatch for each quote file. So it ends up that the entire financial year gets locked while one person saves a change, and two or even three others (working on different quotes for that same salesman) get error messages if they happen to save even a simple item. The alternative with scheduled FFS batches has the same issue, just on a scheduled basis.
Lastly, this then ties into where FFS puts the "sync.ffs.lock" files. because if it still puts it at the top of the folder, then same problem (but it wont last as long because only a limit number of files will be compared/synced). Perhaps a new type of lock file can be used (sync.ffs.zaplock) to only lock either the specific folder in which the specific file is, or even just lock that specific file for editing by FFS.
Anyway, thanks for reading my ideas. Great product. Not knowing much about coding and software development, i can only hope that these might be viable ideas for implementation.
-
- Site Admin
- Posts: 7051
- Joined: 9 Dec 2007
Improving RTS is a ToDo (and there are many improvements possible, including the ones mentioned)
