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).
in case someone feels the need for an immediate solution like me, I’ve made an unofficial build called “v1.9.1”. Please note it’s a build intended for my own use. It’s built on top of v1.9.0 + commit b628ec5054a9ac68d84ef7559017b9c217961f20 with the --no-upgrade switch. I cannot guarantee it’s “safe” for production use and just like to share it.
(Link removed, see calmh’s comment below. I think he’s right.)
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.