GnuCash 2.2.0 under Windows (problems)

Josh Sled jsled at asynchronous.org
Mon Aug 6 21:47:28 EDT 2007


Mike or Penny Novack <stepbystepfarm at mtdata.com> writes:
> As promised, I resumed testing today and have solved the mystery.
[...]
> If the name of the Windows user were "TestOnly" GnuCash will work properly.
> If the name of the Windows user were "Test & Retest" it will not.
> (if curious how I figured out to try this out see *)

This is a great find.  Please file a bug for the issue at
<http://bugzilla.gnome.org/browse.cgi?product=GnuCash>.

When you say "will {,not} work properly", do you mean "basically startup at
all"?  Like, with a space-and-/or-ampersand-containing username, gnucash won't
start up, but with a "simple" username it will?


> If a developer 
> would get back to me with the names of the routines I should examine 
> (those executed when GnuCash comes up the first time and creates the 
> ..gconf directory and its contents) I could take a look before filing the 
> bug report. I did after all offer to analyze the code in cases where a 
> bug was affecting me personally.

It's not quite that simple, unfortunately.

I'm not 100% sure how it works on Windows, but on *nix, the gconf schemas are
installed into the *system* during During the installation process.  When the
gconf values are changed, they're set in the user's .gconf/ storage dir (or
the default value as defined by the installed schema is used).  GnuCash
simply calls gconf-provided API to get and set abstract configuration paths
of the form "/apps/gnucash/dialogs/new_user/first_startup".  The location and
nature of the data storage backing the configuration key/value pairs is
encapsulated from us by gconf.

Thus, I'm wondering if the problem is in gconf or in gnucash.  Most other
gnome libraries are probably going to use the platform-independent system
APIs as provided by glib or gnome-vfs; I would guess that gconf does.  But
there is certainly much file-system and system code in gnucash that does
not.

If would be really great if you could run gnucash under the debugger gdb, and
interrupt it while it's hanging, to ascertain in what part of the code is it
stuck in.  Given that – in my understanding of this problem – gconf2
instances are also running and hung, it would be great to run them in the
debugger as well.  Again, if only to ascertain which stack frame they're
stuck in.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo ${a}@${b}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-user/attachments/20070806/da7186d7/attachment.bin 


More information about the gnucash-user mailing list