[konsole] [Bug 430036] konsole repeatedly losing no-toolbar setting

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=430036

--- Comment #5 from Duncan <1i5t5.duncan at cox.net> ---
(In reply to nick from comment #4) ...

... So no for-sure confirmation on the closing one and immediately opening a
new one race, but dozens of konsoles and no definite negative-confirmation
either, so it's possible.

FWIW, while I may well have high single-digits or even plausibly in the teens
of konsoles open it'd be very rare to have "dozens" open, to the point I'm not
sure I /ever/ have.  But  of about three use-cases here, the one definitely
closes/open konsoles fast enough that one closing could still be writing the
config while another opens, thus producing that race I believe to be the
trigger here.

What we know:

* The no-toolbars config option is is honored at least some of the time, so
it's written and read back correctly, even if it appears to be inconsistently.

* Using a wrapper script that rewrites the konsolerc file from backup before
launch appears to be a solid workaround -- I've *never* seen the problem since
I instituted the wrapper -- so provided konsole can read the config file, it
does seem to do so and the config appears to be correctly loaded from the file
(as long as it can be read).

* SOMETHING is therefore inconsistently either rewriting the config, OR is
preventing reading the config correctly at startup.

Of course my *theory* is that it's the latter, due to the file being locked for
writing by an unloading instance at the same time a newly launching instance
attempts to read it, thus creating a race such that the new instance can't read
the config and defaults to showing the toolbar.  And that both of us use enough
konsoles that it's plausible one is starting while another is quitting
(definitely the case here, plausibly the case for you) would seem to support
the theory.

A plausible second step that just occurred to me now:  While one would hope
that (in this era of limited-write ssds) konsole doesn't needlessly rewrite its
config /every/ time it loads, the logic could very well be that it treats *any*
error reading the config file as if the file doesn't exist, implying it's a
first-run, and thus writes out its default config as what it believes to be the
not-yet-existing file, instead of waiting for a config change to write it out,
as would normally be the case.

That would explain why when it toggles back to show-toolbar, it's then
consistent on every load until the toolbar is manually turned off again.

While I'm not particularly comfortable reading code (and definitely not writing
it, tho I I'm getting a bit more comfortable hack-patching existing code), I
should take a look and see if I can figure out what it's actually doing.  If it
turns out it's either unconditionally rewriting the config at every load, or
it's treating /any/ error reading the config as a fresh config and writing out
the default config...

BTW, I believe you can bug-status confirm the bug if you feel comfortable doing
so.  (I'd feel weird confirming my own bug, but now that you're seeing it too I
believe it's confirmable.)

-- 
You are receiving this mail because:
You are the assignee for the bug.