I haven’t actually got a question, but I tried to report this as a bug and was referred to here instead.
Syncthing Version: v0.14.47
OS Version: Debian GNU/Linux 9.4 (Stretch)
I have two Debian GNU/Linux boxes, both running 9.4. I use Syncthing to back up a reasonable sized (5.4G) working directory between the two. The source machine is set to send only, and the destination machine is then backed up nightly.
Variously spread through the working directory are some symbolic links, all pointing to files also within the tree. The sending copy of Syncthing keeps reporting that it can’t update these symbolic links, although it has successfully copied them to the destination.
If I delete one of them on the destination, then tell the sending end to “Override Changes” then the symbolic link is successfully recreated at the target end, but the sending end still insists that the propagation has failed. As far as I can see, there is no error message associated with the individual symbol links - just a list of them.
As is clear from the explanation which I posted, the screenshot is from the sending side. As I said before, it’s the sending side which complains that it has failed to update the receiver (even though it has in fact succeeded).
Yes, I have checked the logs. As I said before, I can find no error message relating to these files.
It’s not complaining that it failed to update anything. It’s just saying the receiving side has since modified the files, and the send only is out of sync (as it refuses to accept the changes due to it being send only).
Ah - thank you. Some useful information instead of the knee-jerk obstructiveness displayed so far.
It’s useful to know what it’s complaining about, but it doesn’t explain why it’s complaining. These two systems are the only two sharing these files and nothing else is amending them. (There’s a third potential destination-only system, but it is currently powered off and has been throughout the tests.)
The destination system is brand new, and has only just received all the files. Nothing else has amended them since it received them (and it would be slightly weird if there were something at the destination end which went around amending just symbolic links).
As I said before - if I delete the symbolic link on the destination system, and then do “Override Changes” on the source system the link is immediately re-created on the destination system.
What remains a mystery is why Syncthing thinks that, having just created the link on the destination system using information provided by the source system, it nonetheless differs from the source system and needs to be propagated back again. And, no matter how many times one clicks “Override changes”, after a few minutes the error appears again.
That indeed sounds wrong. The first I’d need to know is screenshots from both sides with the involved folder expanded or configs, to know about exact setup you use in order to try and reproduce.
Apologies if I was a little short last night - a long day.
I’ve been investigating further and have found a fix, if not a full explanation.
The sending system in this case is quite old, and has come up through the Debian versions. It’s now running the current issue of Squeeze, but it first had Syncthing installed on it before Syncthing was in the Debian repositories. It therefore has the direct Syncthing repository configured, and was running the latest version of ST.
The receiving system is brand new - commissioned only a few days ago. It has the latest version of Squeeze on it, and I had simply done an “apt-get install syncthing”. It had therefore picked up the version of ST currently in Debian, rather than the latest version.
Sending system: ST 0.14.47
Receiving system: ST 0.14.18+dfsg1-2+b1
As soon as I upgraded the receiving system to 0.14.47 the problem went away.
I still don’t know what caused it, but I observed the same problem on another system (running 0.14.47) trying to send files to the same receiving system (running 0.14.18+…).
Possibly useful for me to document here in case someone else encounters the same problem in the future.
Thanks for reporting back. There were improvements regarding send-only folders since then (0.14.18 is already quite old). I thought those improvements were mainly on the send-only side, but then again there are a lot of changes that could have caused it.
