A problem has just surfaced with 2.5.1 on Windows 11. Gemini thinks it comes from the way the Go code that ST uses processes what is being written to config.xml. They also said I should ask the User Forum before I lodge an Issue.
The crippler is that the config file ends up with lines like this in it:
It seems that an empty field gets split over two lines (
is HTML code for a newline character). Then the server is trying to send files unencrypted but the client is expecting them to come encrypted and these don’t match, so no transfer happens.
I have a markdown file with all the details, ready to submit as an issue, if you think that would be appropriate.
No, it doesn’t make sense, because the display here interprets the HTML-encoded newline character, and I don’t know how to preview the post before sending. Let’s see if this shows what I meant everyone to see:
The crippler is that the config file ends up with lines like this in it:
<encryptionPassword>
 </encryptionPassword>
It seems that an empty field gets split over two lines (`& # xA ;` 
 is HTML code for a newline character).
I do have a screenshot, and I’ll use the upload button to attach it.
Thanks for the additional information. Syncthing itself doesn’t modify those fields without user input, however I’d suggest checking your browser and possibly password manager extensions (if you have any installed) that are most likely to touch them. We’ve had cases like that in the past. You may also want to check what happens when using a different browser.
At this point, you should probably shut Syncthing down, manually change the modified lines in config.xml to just <encryptionPassword></encryptionPassword>, and then restart the application.
Thanks, @tomasz86 , the test computer is not using any password manager, and we have already shut SyncThing down, removed the code for newline and indentation and restarted SyncThing.
When our script runs again, and SyncThing obeys our POST commands, the problem returns. And our POST commands said nothing about encryptionPassword.
I’ll upload a markdown file that contains more details.
It turns out that this problem was caused by our Power Shell script even before it started Syncthing.
So Syncthing is not at fault – sorry for blaming this great software.
Here’s what really caused it.
Our Power Shell script was doing:
[xml]$xml = Get-Content -Path $path
and
$xml.Save($path)
These calls used the .NET Framework that Power Shell runs on, with the effect that the original
<encryptionPassword></encryptionPassword>
was turned into
<encryptionPassword> </encryptionPassword>
When. Syncthing finally saw that, it regarded the newline character and some spaces as the password, producing this
<encryptionPassword>
 </encryptionPassword>
which didn’t match the unencrypted transfer expected by the partner machine.
Isn’t whitespace in XML something that must be ignored though, as per the language specification? Or, at least collapsed into a single whitespace character upon reading. If we do want to store arbitrary characters in there verbatim, including newlines, it should maybe use <![CDATA[MyCrazyPassword]]> in there?
The alternative is entity-escaping the special characters. Which hopefully the Go XML encoder does.
But on reading, unescaped whitespace inside an element’s text content can be reduced to a single space per span, stripping leading and trailing spaces altogether.
I’m surprised that this apparently does not happen when unmarshaling the XML in Go. Are we missing some struct flag maybe?
As far as I understand it, whitespace between elements is ignored (e.g., indentation), but whitespace within a text element is significant. Unfortunately for something like an external writer/formatter it’s impossible to distinguish between the two when there’s no text content yet and there’s no DTD to specify…
