Can't update preferences and can't get rid of Welcome dialog in Gnucash 2.4.7 (OS X 2.6.8)

[prl]

On 9/08/11 17:39, prl wrote:
> On 9/08/11 0:41, John Ralls wrote:
>> On Aug 8, 2011, at 12:25 AM, prl wrote:
>>
>>> On 8/08/11 2:08, John Ralls wrote:
>>>> ... Could you file a bug against GConf complaining that it doesn't 
>>>> handle paths with spaces in them?
>>>>
>>> I've tracked the problem down. ...
>> Peter,
>>
>> Ah, good job.
>>
>> GConf, like Gnucash, uses http://bugzilla.gnome.org.
>>
>> As to whether it will be considered a bug: That's hard to say. I 
>> don't really know any of the current maintainers.
>> It seems that whoever wrote that didn't consider the (admittedly 
>> unusual) use case of putting user home directories somewhere other 
>> than the system default. It certainly seems to me that any legal path 
>> character on the host os should be legal here, too.
>>
>> Regards,
>> John Ralls
>>
>
> I've searched the GConf bugs database for invalid_chars, and the bug 
> has been reported twice:
> https://bugzilla.gnome.org/show_bug.cgi?id=161209
> https://bugzilla.gnome.org/show_bug.cgi?id=640716
>
> The initial report was 161209, and it was reported 6 1/2 years ago 
> (Dec 2004). It seems that there's little prospect of getting it fixed.
>
> I've had a poke around in the GConf source, and I can't see any reason 
> for having this invalid_chars check at all, at least not for xml: 
> configuration sources. The right place to check whether a string is a 
> valid file system path is to ask the file system to do some operation 
> on it. It should tell you soon enough! The invalid_chars string itself 
> makes no sense, either as a list of invalid characters in a URI (which 
> a GConf source address superficially resembles) or as a list of 
> invalid Windows filename characters (and anyway, why should Linux and 
> OS X be made to suffer for the shortcomings of file names in Windows?).
>
> If such an invalid characters test were to have any place it should 
> probably be in the configuration source backend, not in the common 
> GConf code anyway.

Since it seems unlikely that the bug will be fixed in the near future, 
here's a hack that stops OS X GConf rejecting configuration source paths 
that have spaces in them (tested only on OS X Gnucash 2.4.7 r20812MS!):

    Cambyses:~ prl$ cd /Applications/Gnucash.app/Contents/Resources/lib
    Cambyses:lib prl$ mv libgconf-2.4.dylib  libgconf-2.4.dylib-
    Cambyses:lib prl$ cp libgconf-2.4.dylib- libgconf-2.4.dylib
    Cambyses:lib prl$ dd if=libgconf-2.4.dylib- bs=1 count=36874 >
    libgconf-2.4.dylib
    36874+0 records in
    36874+0 records out
    36874 bytes transferred in 0.240498 secs (153324 bytes/sec)
    Cambyses:lib prl$ dd if=/dev/zero bs=1 count=1 >>  libgconf-2.4.dylib
    1+0 records in
    1+0 records out
    1 bytes transferred in 0.000027 secs (37118 bytes/sec)
    Cambyses:lib prl$ dd if=libgconf-2.4.dylib- bs=1 skip=36875 >> 
    libgconf-2.4.dylib
    185021+0 records in
    185021+0 records out
    185021 bytes transferred in 1.092999 secs (169278 bytes/sec)
    Cambyses:lib prl$ ls -l libgconf*
    -rwxr-xr-x@ 1 prl  admin  221896 Aug 11 12:23 libgconf-2.4.dylib
    -rwxr-xr-x@ 1 prl  admin  221896 Jul  3 04:56 libgconf-2.4.dylib-
    Cambyses:lib prl$ cmp -l libgconf*
      36875  40   0
    Cambyses:lib prl$

The idea is to replace a 0x20 (space) byte in the instruction "cmp 
$0x20,%cl" at 0x9008 in libgconf-2.4.dylib with 0, which converts the 
instruction into "cmp $0x00,%cl". 0x9008=36872 and the 0x20 byte is two 
bytes from the start of the instruction, so the byte at 36874 is being 
modified. The cmp utility counts bytes starting at 1, not 0, so it shows 
the changed data location "off" by one byte, but it's in fact correct. 
The display of the byte differences from cmp display in octal, hence the 
40 rather than 20.

An instruction is being modified rather than the invalid_chars string 
because of the way that gcc has optimised gconf_address_valid(). By 
modifying the invalid_chars string as well, it's also possible to change 
the set of invalid characters, or to turn the test off completely.

It's probably not a good idea to apply the patch if you don't know how 
the above could work. Even better, you should examine the 
libgconf-2.4.dylib binary with a disassembler or gdb to see what it 
actually does.

Cheers,
Peter