From: Richard Frith-Macdonald <richard@brainstorm.co.uk>
Date: Tue Aug 27, 2002 11:31:43 AM Europe/London
To: Stefan Urbanek <urbanek@host.sk>
Subject: Re: Defaults being destroyed (Solved?)
On Tuesday, August 27, 2002, at 10:49 AM, Stefan Urbanek wrote:
On 2002-08-27 10:14:11 +0100 Richard Frith-Macdonald
<richard@brainstorm.co.uk> wrote:
The patch actually makes no functional change that I can see ...
In the original implementation, all domains, that were not present at
the tool startup were later considered as removed by the tool.
I don't see that.
In my patch, only domains removed by the tool are removed from
database. But may be I have overlooked something in the sources...
To be marked as having been removed, the __changedDomain: method would
have to be called,
and I don't see any mechanism by which that could happen simply because
the defaults were
not present at startup.
I think perhaps your test code is not reliable for reproducing
your problem. It failed to show up anything on an unmodified
system for me.
For me, the script (that was attached) will show, that the domain will
be removed after 30 seconds each time it is run. Note, that no other
GNUstep applications/tools are running while the test. The defaults
are being corrupted even now with the locking.
Ok ... that doesn't happen on my RedHat, Debian woody intel or Debian
woody ppc systems.
I guess that the best thing to do would be for you to put some logging
code into the synchronize
method to see what ti thinks it's doing ... then run your gdnc process
and observe the results.
Better still if you can run it under gdb and step through to observe
things.
Another idea is to have something like UserDefaults distributed
object. The problem is, that defaults database management is
decentralised and such object will make the management easier and will
take care about consistency.
What do you think?
I think it's missing the point ... if you don't know what's causing the
problem
then you could end up writing a new implementation which has the same
faults!
To me, the rational approach seems to be to reproduce the fault,
understand it,
and only then to try fixing it.
The bug (now fixed) that Alexey spotted in NSData is the only thing
I've seen which
would cause a loss of the defaults database. Of course, any app can
replace a
domain, so there could easily be a bug somewhere other than in the
defaults system
itsself ...