Re: Defaults being destroyed (Solved?)

[Stefan Urbanek]

On 2002-08-27 11:31:43 +0100 Richard Frith-Macdonald <richard@brainstorm.co.uk> 
wrote:

Okay, after thousants of NSLog lines here it is:

In NSUserDefaults around line 1301 in -synchronize:

     if (![_persDomains writeToFile: _defaultsDatabase atomically: YES])
        {
           NSLog(@"Error while writing");
          [_fileLock unlock];
          [_lock unlock];
          return NO;
        }
     ASSIGN(_lastSync, [NSDate date]);
+     RELEASE(_changedDomains);
+     _changedDomains = nil;

Last two lines have to be added.

If the tool (gdnc in my test) was run for the very first time it will create 
missing domain for the process and NSGlobalDomain. Those domains are marked as 
changed, and because they were just created, they are empty. After 
synchronizing, empty dictionaries are written. _changedDomains was not cleaned 
after syncing, so the domains were empty on each sync.

Stefan


> 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 ...