Background:
- Freefilesync is an executable, only run when opened manually or activated by RealTimeSync
- RealTimeSync only detect change or directory availibility, then call FreeFileSync to open the batch job and do whole scanning.
- everytime i turn on my laptop RealTimeSync will kick in and FreeFileSync will scan the whole pair with no particular reason.
- most of the time i turn on my laptop to do something that need most of my resource, but windows 8.1 have a problem with disk usage. when disk is used heavily by FreeFileSync, the entire desktop lag alot.
- that is why i like to cancel the scan, and dedicate a free time to let it do its job.
My proposed solution:
- After initial whole scan, and sync, user can set how the program run on startup. then prompt the user to restart.
- instead of using separate executable, FreeFileSync should run in minimalist monitoring mode (call it process 1) (D:\)
- when changes are detected on monitored folder,
example folder D:\alpha\ or certain file D:\alpha\readme.txt
it will change to processing mode, run the comparation scan only on associated sub-directory pair, instead of the whole directory. this process only compare and sync, doesn't do any monitoring.
- the process also spawn another instance of subtitute (similar) process to monitor other change (call it process 2), and send parameters to it.
- process 2 will monitor all directory as usual, but ignoring the sub-directory (folder D:\alpha\) being processed by process 1
- After finishing its job, process 1 will wait for x seconds, do the scan and sync again, repeat. after no change detected, send parameter to others (process 2, 3, 4, ...) to stop ignoring folder D:\alpha\, then terminate itself.
- there should be 1 process doing the monitoring mode, (no more, no less) and any number of scanning-and-syncing process.
- if the change only happen to files D:\alpha\readme.txt, there is no need to scan subfolder D:\alpha\anotherfolder_b\ because there is no direct change in the subfolder.
- because of spesific job (usually only a subfolder scanned) there should be no problem and limit from spawning multiple process.
with this, the job and weight will be separated, and consume less time
Feature request, "True monitoring" only scan detected change.
- Posts: 2
- Joined: 23 Feb 2016
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
For laptop syncs it might make sense to set RunWithBackgroundPriority:when disk is used heavily by freefilesync, the entire desktop lag alot
https://freefilesync.org/manual.php?topic=expert-settings
Currently RealTimeSync doesn't make it easy to see which file triggered the sync. (It is possible though!) It's planned to add some kind of log window.everytime i turn on my laptop realtimesync will kick in and freefilesync will scan the whole pair with no particular reason
Might or might not be very useful. Usually the OS buffers all file system accesses so that only the first FreeFileSync comparison is slow while subsequent syncs return buffered data for the most part.[Partial scanning]
- Posts: 1
- Joined: 30 Apr 2016
My first post on this forum. First of all, thanks for putting up effort for creating such a good tool. Well done job!
I totally agree with the OP. Improving real-time sync performance is probably the No. 1 feature you should focus on. OS-level buffering still doesn't make it enough fast. It takes minutes for FreeFileSync to sync my PC and laptop every time I change something on one machine (I'm a dev myself and keep my two machines sync using FFS). I used free trial of GoodSync for some time which used to perform real-time sync between these two machines under a second.
Perhaps an easy workaround could be to allow FFS to accept source and target directories as command-line parameters (instead of a batch file). Then keep listening to OS notifications for a file change and upon receiving a notification, send the source and target directories to FFS through command-line for a sync. This will still be far faster than doing an thorough sync.
I totally agree with the OP. Improving real-time sync performance is probably the No. 1 feature you should focus on. OS-level buffering still doesn't make it enough fast. It takes minutes for FreeFileSync to sync my PC and laptop every time I change something on one machine (I'm a dev myself and keep my two machines sync using FFS). I used free trial of GoodSync for some time which used to perform real-time sync between these two machines under a second.
Perhaps an easy workaround could be to allow FFS to accept source and target directories as command-line parameters (instead of a batch file). Then keep listening to OS notifications for a file change and upon receiving a notification, send the source and target directories to FFS through command-line for a sync. This will still be far faster than doing an thorough sync.