Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Syncthing should guard against running old versions with new config #4921

Closed
ssergiienko opened this issue May 5, 2018 · 5 comments
Closed
Labels
enhancement New features or improvements of some kind, as opposed to a problem (bug) frozen-due-to-age Issues closed and untouched for a long time, together with being locked for discussion good first issue Good starting points for new contributors
Milestone

Comments

@ssergiienko
Copy link

Problem:
I have latest release of Syncthing (v0.14.47) and during development & debugging I accidentally run older version of Syncthing v0.14.(4 or 17) and it was successfully started in background because config paths are the same (defaults).
Now, my config.xml becomes a mix of old-style and new-style options but still has version=28 and who knows what can happen to other files if version will be even older(e.g. db format incompatibility).

For example:

 <configuration version="28"> # both files

-        <minDiskFree unit="%">1</minDiskFree>
+        <minDiskFreePct>0</minDiskFreePct>
-        <pullerMaxPendingKiB>0</pullerMaxPendingKiB>
+        <pullers>0</pullers>

What's expected? One of this:

  • it should fail to start early with appropriate message unless some special option is used like --allow-downgrade (or whatever)
  • or at least start in read-only mode for everything

Version Information

Syncthing Version: Any
OS Version: Any

@ssergiienko ssergiienko changed the title Syncthing should have guard from running old versions with new .config/* files Syncthing should have guard against running old versions with new .config/* files May 5, 2018
@AudriusButkevicius
Copy link
Member

AudriusButkevicius commented May 5, 2018

I don't see an actual problem though. If something was incompatible, I guess I would expect it to fail. If it didn't, it's probably ok. The new/old config stuff would get cleaned up on first config save.

@calmh
Copy link
Member

calmh commented May 5, 2018 via email

@calmh calmh added enhancement New features or improvements of some kind, as opposed to a problem (bug) good first issue Good starting points for new contributors labels Jun 26, 2018
@bahadir60
Copy link
Contributor

@calmh, @AudriusButkevicius, @ssergiienko Hi there,
I wanna work on this ticket. As I understand the problem, besides the different Syncthing versions, they have different GUI Configuration versions (28 and 25). So that don't let loading config.xml for older Syncthing versions and logged "Version Conflict" with Exit code is appropriate to solve the problem. Any suggestions or comments??
Thxs.

@calmh
Copy link
Member

calmh commented Sep 3, 2018

Mmm, yes. There's a current config version, defined somewhere in config.go I think. If the config on disk has a higher number than that, it has a newer schema that we by definition don't understand.

There's a place in main.go where we check if the config was upgraded, which might be a good place to also check if the config version is too high and abort.

Alternatively the check could happen already in the config loader, but it would be nice to be able to force a start with --allow-downgrade or something, in which case having the config loader throw an error might be annoying. We don't want to pass parameters like that down to the config loader. On the other hand, having the check there and returning a known error could work. That also means we'd automatically catch things like someone posting a too new config over the API as well.

@bahadir60
Copy link
Contributor

@calmh Thanx, I will work on it and implement ASAP

@calmh calmh added this to the v1.1.1 milestone Mar 12, 2019
@calmh calmh changed the title Syncthing should have guard against running old versions with new .config/* files Syncthing should guard against running old versions with new config Mar 28, 2019
@st-review st-review added the frozen-due-to-age Issues closed and untouched for a long time, together with being locked for discussion label Mar 12, 2020
@syncthing syncthing locked and limited conversation to collaborators Mar 12, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New features or improvements of some kind, as opposed to a problem (bug) frozen-due-to-age Issues closed and untouched for a long time, together with being locked for discussion good first issue Good starting points for new contributors
Projects
None yet
Development

No branches or pull requests

5 participants