Feature Request: Don't Use Standard Rescan Interval for Missing Folder Paths

Hello:

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.

Does that make sense?

But if your interval is 6 hours your stuff might not get synced for 6 hours anyways, regardless if its plugged in or not? Don’t see how marker missing makes this a special case?

What are you trying to solve?

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)).

Hi:

Ok - I’ll put some specifics in here. Let’s say:

  • 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.

I guess can we not leverage fs watches to discover when a folder has recovered?