I would personally suggest to keep at least one of the machines online all the time. When idle, a desktop can use as low as 20~30W, which shouldn’t really affect your electricity bills, and this should prevent potential conflicts.
In Windows, I use the Task Scheduler to change the power plan to Power Save when idle, which I have customised to limit the CPU speed to minimum. The same can be done with CPU governor tweaks in Linux.
Since Syncthing is completely peer-to-peer, there is no way to sync files without at least 2 machines up and running at the same time (which makes it different from other, cloud-based solutions).
I’m working on solving the machine sleeping, and hopefully am making progress on that front.
I am running into another issue, and am wondering what is going on, and how to fix it.
I use the KOrganizer in KDE to keep my calendar, and in an effort to keep my calendar synced between the machines, I created an .ics file in one of the directories that is synced and set it to be the file that all the machines use. The calendar configuration has a setting “File monitoring” w the note
If file monitoring is enabled the resource will reload the file when changes are made by other programs. It also tries to create a backup in case of conflicts whenever possible.
I have this enabled on all three machines. If I understand the description, if I make a change in the calendar on the machine I’m using, the updated ICS file should sync to the other machines, (overwriting the copy on those machines) and then KOrganizer should simply see the file change on disk and update itself…
Instead I seem to get a cascade of sync conflicts that add another conflict file every few seconds… What is happening and how do I fix it?
I have a feeling that this has more to do with the calendar application than Syncthing.
I would pause the Syncthing folder in question on all devices, and then just observe the ICS file itself to see what really is going on with it (i.e. does the file itself keep changing, does the mtime get updated, etc.).
If there is nothing obvious, then I would suggest doing more testing with just 2 devices first.
I have paused it on the two machines I am at right now, I don’t see an obvious way to pause it on the remote machine? (am I missing something?)
I watched the ics file on one of the paused machines and it didn’t seem to change except when I created a test appointment, which updated it once to the time of the new appointment (which I think is the expected behavior)
I just paused Bill-box on T540 and Coolbox, and deleted the existing conflict files.
I then made a change in the calendar on Coolbox, which updated the .ics file, as expected. Since the folder was paused, it didn’t propogate the changes to T540, again as expected.
Then I unpaused the folder on it and T540, and almost immediately got 3 conflict files on both machines. Two were dated from the previous file (which would have been the one on T540) one each for the .ics file and it’s backup. The third was a backup for the current .ics file. About 5 minutes later, I got a 4th CF file for the backup. The regular .ics and backup updated on T540
Since then, without making any changes to the calendar about once a minute, I see ST doing a scan of the folder and go into syncing for a few seconds, and the M-stamp on the .ics file updates to the current time. (The time does not change when ST isn’t attempting to keep the file synced)
I also tried making a new test appointment on each machine with ST working and it appears to have synced to the other w/o creating any new conflict files in each case the first time I did it, but did the same set of three files when I tried it a second time.
I also tried pausing / resuming the folder on Coolbox without making any changes in the calendar, and did not get new conflict files.
So the syncing seems to be doing the right thing, sort of except for the frequent rescans when there are no changes. and creating the conflict files in some cases but not others when making changes to the calendar.
It seems as if the calendar software treats accessing the file by Syncthing (via the scanning process) as a “modification”, and then it also updates its modification time accordingly, which then triggers Syncthing too.
I guess that you could possibly work around this by setting Max Conflicts to 0, but really, this sounds like an issue with KOrganizer rather than anything that Syncthing can handle.
However, even considering the above, Syncthing should normally only rescan all files every hour (3600s), which is not that often, unless you have disabled the file watcher and/or changed the default settings.