changed the way we create the '~/.fluxbox' directory to avoid race conditions

before bringing up the first instance of Fluxbox we prepare the directory
and the files it needs. if the config version of exiting files is lower
than what we expect, we upgrade the config files. after that we bring
up Fluxbox.

the old way was problematic because setupConfigFiles() calls
'fluxbox-update_configs' which does its job in the background while
fluxbox continues to boot. 'fluxbox-update_configs' sends a USR2 signal
to the booting fluxbox (it might even be finished, no one knows) which
triggers 'load_rc()' which triggered 'setupConfigFiles()' again which
might trigger 'fluxbox-update_configs' again (on my machine
'fluxbox-update_configs' was called 3 times and left a pretty crippled
'keys' file when it was done).

bootstrapping before bringing up fluxbox resolves the issue. as a bonus:
no need to send USR2 to fluxbox to reload the config file because fluxbox
has not even tried to read it yet.

1 files changed, 1 insertions, 1 deletions

diff --git a/util/fluxbox-update_configs.cc b/util/fluxbox-update_configs.cc
index 292fe92..39539f8 100644
--- a/util/fluxbox-update_configs.cc
+++ b/util/fluxbox-update_configs.cc
@@ -563,7 +563,7 @@ int run_updates(int old_version, FbTk::ResourceManager &rm) {
     string appsfilename = FbTk::StringUtil::expandFilename(*rc_appsfile);
     string keyfilename = FbTk::StringUtil::expandFilename(*rc_keyfile);
 
-    size_t i;
+    int i;
     for (i = 0; i < sizeof(UPDATES) / sizeof(Update); ++i) {
         if (old_version < UPDATES[i].version) {
             UPDATES[i].update(rm, keyfilename, appsfilename);