Possibly a niche feature request here: as I understand it, if a folder path is missing when Syncthing attempts to scan it, it will wait for the defined rescan interval when attempting to scan again.
Can I propose a different interval is used in the case where a folder path is missing (I propose 60 seconds)? Two personal use cases would find this useful:
A machine with a removable drive which holds a shared folder. In a typical, default setup with the Fswatcher enabled the rescan interval is set to 1 hour - which means the drive is potentially not going to be synced until 1 hour after plugging it in;
A machine with an external storage device which boots quite lazily, and isn’t mounted by the time Syncthing starts. In my case here I have a large archive folder which I don’t want scanned very often - so I’ve set the rescan interval to 6 hours. Consequently, this folder isn’t going to do anything for most of the day.
I think the relevant part is the filesystem watcher: Having that enabled means in normal operations you have near instantaneous scans, but after mount you need to wait for up to an hour by default for a scan. This could be improved by setting up a watch when the folder marker goes missing (or just not stop the watch on folder error, but I assume doing that had a point (don’t remember what it was though)).
I work on my computer for 8 hours a day, and power down each night;
Scanning my large archive folder takes 2 hours to complete;
I have my rescan interval set to 6 hours, and have the Fswatcher enabled. Due to the large number of files, I don’t want to have scheduled scans running more frequently - increased disk wear, increased resource usage, etc.
With the current setup:
For the first 6 hours of the day, nothing will happen as the volume wasn’t present when Syncthing first started;
For the next 2 hours of the day, Syncthing will be scanning the volume before it starts syncing;
And then I shut down the computer. And no syncing has happened.
With the proposed setup, I’ll get much more syncing done during the day.
Admittedly this is not a usual requirement, I admit - but the first use case (a machine with a removable drive), I suspect the general expectation is that syncing will start much more promptly than the default schedule of up to an hour’s delay.