What information can I provide to help tracking down this issue?
BTW: On Linux the scan times are the same for 1.8.0 and 1.9.0: Approx 12 seconds on a Celeron G3900T @ 2.60 GHz. So this linux machine was always much faster than the Windows devices…
The scan process has changed in order to handle case insensitive systems. It does more work so it’s expected that it’s a bit slower. However my benchmarks showed roughly what you see on Linux, so I think it’s unexpected that it’s that much slower on Windows.
Currently I’m feeling “no”, as it’s not a functional problem and we’ve had it out in an RC for a while without any complaints.
But I plan to drop 1.10.0-rc later this week, which includes the fix, so those suffering mightily can hop on that train.
Or, worst case, set the caseSensitiveFS advanced folder option to disable the new checks. This brings back the 1.8.0 scanner, both performance wise and will-fuck-you-up-if-you-have-case-mismatches wise.
just to add another datapoint, rescan time on my windows systems (~220k files, 60GiB) went from ~5-10 minutes to hours (unknown how many, 4+; I gave up and set the caseSensitiveFS flag after I found this post as it was blocking any syncing from actually happening).
Please don’t do that. I know you mean well, but random patched Syncthings with what looks like a real official version number that doesn’t exist and upgrades disabled is something that makes me somewhat unhappy.
Do what you like on your own systems, of course, but once you start distributing binaries either do it properly and disclose the modifications and distribute the source, or don’t do it. Please.
We might release a 1.9.1 tomorrow to fix a critical issue and then anyone with your binary is in a mess.
If anyone is in an extreme hurry for a fixed binary, our nightly builds are that.