I can’t reproduce that. Can you describe a bit more about what you mean?
after upgdate to rc3 I run syncthing.exe -reset. look on next shot
wheh I press “Rescan” in rc3 - nothing happens.
1 Like
It looks like the first folder, redminebackup got scanned correctly. Is there anything different about it?
no, this not scaning correctly too, but very fast recive replica of this folder from remote server (on linux)
1 Like
Ok, yeah, I can confirm there’s something broken on Windows.
Fixed, dropping a quick -rc4 to handle 
… and an -rc5 because there was an annoying deadlock.
1 Like
Uhh-ohh, considering documentation was updated just a couple of days ago Haven’t skimmed through it though, maybe it can be implemented quickly.
On the protocol side, a few fields have been added to the ClusterConfig, that’ll take you five minutes to add. The Ping/Pong mechanism is changed to just a Ping every 90s (in the absence of other traffic) and no Pong.
The rest is the the discovery, which is obsviously different, and relaying which is very optional.
How important is the https://relays.syncthing.net/endpoint for relays to work? Meaning, do we have to replace that with an IP for Android?
Essential. Yes. And some hack may be required for the certificate to be accepted… There’s also the discovery servers at https://github.com/syncthing/syncthing/blob/master/lib/config/config.go#L40 which has IP variants a bit further down, but currently no code to “activate” them. If I remember correctly there’s an android build flag we should trigger on for that…
@AudriusButkevicius Now that we have a proxy dialer function everywhere anyway, perhaps we could simply have a hack in the dialer function that uses a map[string]string of hard coded mappings for DNS… Unless this has finally been fixed in Go 1.5 or something.
Yeah I guess that would be the easiest place to hack it in, though I am not sure if that solves the http problem.
I am sure this got fixed as the ticket is closed, we just don’t know how to use the fix.
I’ve already added the code to replace announce servers in the config link.
Iirc the DNS works only with cgo, which we don’t use? Anyway, I’ve tried to get a build with Go 1.5, but I didn’t get it to work yet (on the go1.5 branch).
We can use cgo, it’s just a matter of having the right bits in place when doing the build. I remember that the GOOS=android thing (which should be the right solution) requires having the Android SDK and stuff, and didn’t want to get involved in that. But I would guess that a build done like that should have working DNS, if the issue has been resolved.
BTW, I plan to release v0.12.0 on Thursday, Nov 5. I’m away traveling on the 2nd-4th, and experience tells me we might want a v0.12.1 quite soon after v0.12.0, so better to be in the vicinity of the Internet then.
3 Likes
Yeah I tried that, but I couldn’t really figure it out (got some build errors).
Maybe you guys can have a look at it here.
Here’s a binary built for GOOS=android using the SDK and everything, using xgo.
http://build.syncthing.net/job/syncthing-xgo/
I’d be interested to see if it has working DNS resolution or other awesome advantages… (It calls itself unknown-dev for xgo related reasons, but it’s the latest master.)
Indeed, that was easy.
I’m eager to see relay documentation to tinker with it.
1 Like