v1.27.1 crashes on Windows 7 and Windows Server 2008
vector090 opened this issue · 15 comments
Does your log mention database corruption?
Not sure.
Include required information
-
which version of Syncthing and what operating system you are using
1.27.1 Windows
Fresh downloaded, and files are intact. -
what happened,
D:\syncthing-windows-amd64-v1.27.1>syncthing.exe --version
Exception 0xc0000005 0x8 0x0 0x0
PC=0x0
runtime.asmstdcall()
runtime/sys_windows_amd64.s:65 +0x75 fp=0x22fca0 sp=0x22fc80 pc=0x473dd5
rax 0x0
rbx 0x1a27f20
rcx 0x1a88240
rdi 0x7fffffde000
rsi 0x22fea0
rbp 0x22fde0
rsp 0x22fc78
r8 0x0
r9 0x22fee0
r10 0x1a59a38
r11 0x21
r12 0x22fec0
r13 0x1
r14 0x1a27480
r15 0x0
rip 0x0
rflags 0x10293
cs 0x33
fs 0x53
gs 0x2b
- what you expected to happen instead, and
- any steps to reproduce the problem.
Old version works, till syncthing auto upgrades to 1.27.1.
D:\syncthing-windows-amd64-v1.27.0\syncthing-windows-amd64-v1.27.0>syncthing.exe -version
syncthing v1.27.0 "Gold Grasshopper" (go1.21.3 windows-amd64) builder@github.syncthing.net 2023-11-27 03:45:21 UTC
Due to being compiled with Go 1.21, Syncthing no longer supports Windows 7 (see https://forum.syncthing.net/t/syncthing-crashing-after-updating-to-v1-27-1/21248). If you want to continue using Syncthing on that device, you will have to downgrade to v1.26.1 and disable automatic upgrades. How to do so is described in the linked forum topic.
Of course, I'm assuming that this is Windows 7, as no specific information has been provided about the OS. Please write back if it's not Windows 7 and you experience the crash on a newer version of the OS.
Indeed it is Win7.
would be nice if a file synchronization software didn't autoupdate itself into being broken, thanks
not supporting w7 is one thing (i get that it's upstream devs being lazy and not something syncthing can do anything about), but at least have a check "IF NT<=6.1 THEN give a warning and don't break yourself", especially if fixing the situation requires a notable amount of work! also, this is a minor release, no?
this is a seriously bad look
The problem is that this kind of incompatibility is usually discovered after the fact (especially since the very previous version still worked in Windows 7 even though the OS wasn't supported by the compiler already). This means that even if implemented now, it would already be too late.
On the other hand, if you run an unsupported/outdated operating system, applications are bound to break at some point, so if you need to stick to the specific OS, the best practice is probably to disable any kind of automatic updates in advance anyway…
The alternative would be to drop support as soon as Go does and implement an OS version check to disable automatic upgrades. That would make other people angry, because things might still work for one or two Go releases.
There's also a chance that the check is buggy and we end up with a lot of installations refusing to auto-upgrade.
Decided to pin the issue to avoid duplicates.
same here discovered on an older laptop today which occasionally syncthings stuff, but is still on win7. any chance? rebuild for win7 users as well in separate tree? win8 and stuff? thanks.
also: didnt see any real information comparing 1.27.0 and 1.27.1 that would bring up such a hint about newer go version and platforms being used or stuff being dropped? thanks.
The problem is that this kind of incompatibility is usually discovered after the fact (especially since the very previous version still worked in Windows 7 even though the OS wasn't supported by the compiler already).
while I do get that, Go did announce they'd drop support, so breakage was expected to occur. I'd normally not be that upset as I do know the struggle of supporting fringe configurations, but for this genre of software it would've been nice to consider warning about lack of w7 support (idk, put a banner in the webUI), then doing basic testing on w7 releases from that version onward. That wouldn't catch all the possible bugs but the only one you really have to care about is lack of ability to launch, or serious data loss. (After all, most other bugs could be autofixed with another update, and you've already publicly announced lack of support.)
I'm assuming in this that yall did skim release notes for Go when updating it (sadly this seems to be not so common, and often a major reason for w7 support to disappear in applications where it really isn't warranted).
It's a bit troubling to find your ST broken, seeing it's autoupdating to a broken executable as soon as you try again, to have to go on GH to find a random bug report (hidden under the Closed section) for a dev to respond it's no longer supported after the fact. I personally don't use ST for anything critical, but I would not be surprised if there are people who do, and those just so happen to also be the people using older OSes.
In fairness, I'm nitpicking a little (I do have to say, thank you to whoever thought of backing up the old executable on updating, as well as making disabling update as easy as running it with STNOUPDATE=1, then allowing you to go into settings and disable it), but I think it's healthy to nitpick like this for software relied on for data integrity. With how the tech world is moving, support lifecycles seem to be shortening again hard (once "w10 and up" becomes the requirement, I tend to see a lot of devs quickly sliding to "22h2 and up" and similar cycles), so a plan for support lifecycles is pertinent. For the current case, I'd say you should try damage control a little; put up posts very clearly stating Windows 7 is no longer supported, so people with a suddenly broken ST will know what to do.
then doing basic testing on w7 releases from that version onward.
The project's stance on EOL platforms can be summed up as "we try not to actively break things if we don't have to", but that's about it. If someone wants to do the testing and contribute patches to keep the platform alive, we won't block them.
I personally don't use ST for anything critical, but I would not be surprised if there are people who do, and those just so happen to also be the people using older OSes.
Running anything mission-critical or network related on an OS that's been EOL for about 4 years is a recipe for disaster. That said, people are free to do so, and we're not going to stop them.
For the current case, I'd say you should try damage control a little; put up posts very clearly stating Windows 7 is no longer supported, so people with a suddenly broken ST will know what to do.
👍
Downgrade link: https://github.com/syncthing/syncthing/tree/v1.26.1
Or possibly: https://github.com/syncthing/syncthing/tree/v1.27.0
the world wouldn't end if version numbers were integers (ignoring release notes is a bad idea), and though i have a history of maintaining APIs, i know systems can sprout features without corresponding API changes. in this vein, i do not assume that everyone uses SemVer correctly, so i would have updated Syncthing's version number to 1.28.0 instead of 1.27.1 because incrementing the minor version number is always safe whereas analyzing the 1.21.4→1.21.5 Go upgrade was a nonstarter.
Windows is my least favorite operating system and the versions mentioned are quite old, but i am sympathetic because using ancient macOS hosts isn't that different. an old version of macOS doesn't just build Syncthing from source, it also builds Go. so a minor version number change hints at the possibility of an upgrade being more expensive than usual. it might be time to turn on the fan :-)
(i run 1.27.2 on these hosts, and upgrading monthly has been easy. this is great software, maintained at a very high level.)
Pubic Service Announcement:
Last Working Version for Windows 7 is v1.25.0 (from my testing)
Download Syncthing v1.25.0 64bit here:
https://github.com/syncthing/syncthing/releases/download/v1.25.0/syncthing-windows-amd64-v1.25.0.zip
If you're an advanced user 32bit https://github.com/syncthing/syncthing/releases/download/v1.25.0/syncthing-windows-386-v1.25.0.zip
running v1.27.0 without any problems, just make sure to disable automatic updates
Due to being compiled with Go 1.21, Syncthing no longer supports Windows 7 (see https://forum.syncthing.net/t/syncthing-crashing-after-updating-to-v1-27-1/21248). If you want to continue using Syncthing on that device, you will have to downgrade to v1.26.1 and disable automatic upgrades. How to do so is described in the linked forum topic.
Of course, I'm assuming that this is Windows 7, as no specific information has been provided about the OS. Please write back if it's not Windows 7 and you experience the crash on a newer version of the OS.
If I compile syncthing with Go 1.20, latest Syncthing will run on win7 continuely?
The latest Syncthing version tends to gradually make use of newer language features. So I doubt that it will compile or at least it will break in the very near future.