https://bugs.kde.org/show_bug.cgi?id=430036
--- Comment #5 from Duncan <1i5t5.dun...@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 watching all bug changes.
