Enable stopped folder if it's healthy when a pull is started

[bedosk]

Currently syncthing will reconnect and rescan folder when periodical or manual rescan is requested. I'd like a feature to just reconnect folder without rescanning and then follow the folder's rescan interval settings.

[calmh]

"Reconnect" here refers to a folder having been stopped due to path or marker missing, and the request is for this to happen when scanning is disabled and Syncthing wants to pull something.

[AudriusButkevicius]

Why does this matter?

[AudriusButkevicius]

Context to this:
https://forum.syncthing.net/t/reconnect-folder-after-share-drive-reattached/8040

Why would the rescan take an hour if nothing is changed? I am personally in favor of the current implementation.

[bedosk]

It takes so long because it's low spec machine and basically that's the time it takes just to walk through 400k files and compare it with db. No hashing because no files are modified.

[AudriusButkevicius]

Sure, but the problem is that you are using a low spec machine for 400k files, not the fact that we want a recan on status change. Running with scans disabled is already suboptimal, as various maintenance tasks are not performed, as well as the unscanned node could essentially cause other nodes to look like they are failing to sync.

My point is, what you are doing is not right, and I am not convinced we should add workarounds for scenarios which are not right

[bedosk]

So I see this differently. It's user choice to disable scanning and this option is available. All I'm saying is to reconnect shares and follow rescanning intervals. That way users with scanning enabled wouldn't be affected as their shares would be rescanned and users who chose to disable scanning would have it that way.

[calmh]

I was also thinking that disabling scanning is a somewhat odd way to use Syncthing, but the fact is that we do allow doing that, that it shouldn't cause any serious issues (we will still inspect and rescan before overwriting if necessary), and it should be no hardship to run the health check at the start of a puller iteration so I think this is valid.

[AudriusButkevicius]

We allow that for a specific usecase, that is when inotify is used instead of scanning, which is the only reason we allow that as far as I recall. Abusing that for your own means should not be encouraged, as if this becomes a fashion statement for rpi users or something like that, the amount of "the peer who had the file went away" complaining threads on the forums and issues on github will be phenomenal.

[bedosk]

So I just want to add one probably key piece of info. I'm using Master enabled shares. So I don't see a reason for rescan on a slave any time hence rescan=0.
I agree with you Audrius that if you don't run master folders (or inotify) disabling rescan doesn't make any sense.

[AudriusButkevicius]

It doesn't matter, the fact that you run master or not means nothing in this context, as master does not enforce others to have the correct data, especially when scanning is disabled and others themselves have no idea if they have the correct data... Yet they advertise that they have the correct data and are allowed to be used as a source of data which potentially could be completely incorrect and full of garbage...

It gets even worse if master for some reason goes offline and suddently we know the correct state we need to achieve, but we can't find the correct data anywhere