On Wed, Feb 18, 2026 at 02:42:28PM +0000, Weis, Benedict wrote: > Hi Willy, > > alright, your idea for state file v2 sounds like a solid improvement. Is the > proposal documented/tracked anywhere?
Not that I remember. We just anticipated it at release time so that the first line of the file contains a "1" which means "version 1", because we suspected such issues would pop up over time. It "just" requires to have someone start working on it, and it will clearly be a tedious task. One of the issues I remember about is that a lot of settings don't have an "initial value", i.e. they have a single value, which is the one that is being changed at run time. So a first change will require us to be able to keep a copy of the initial values at startup time somewhere (and probably only when state-file is in use). This alone is not trivial because some elements directly come from the "server" line and others might be resolved a bit later when the config is consolidated (though I don't have examples of this, and in an ideal world I would just be wrong so that it would be easier to implement). Note that we could also imagine a much simple and probably sufficient approach: just compute a hash (e.g. XXH64) of all the arguments of the server line, store it in the server struct, and compare it at boot. If it changes, then the new server line entirely ignores the state file because someone touched the config; otherwise we'd keep the values from the state file (including the port etc). Please understand that it's not exactly a proposal, it's an idea that comes to my mind right now and that I'm exposing. It might very well not suit all use cases, and some might disagree with it, which is fine. But maybe that could be easier for everyone at a very low engineering (and user) cost. Willy
