Re: Defaults being destroyed (Solved?)

[Richard Frith-Macdonald]

On Tuesday, August 27, 2002, at 01:27 PM, Stefan Urbanek wrote:

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

I'd already modified the code to put DESTROY(_changedDomains) at line 
1304 when
I added the locking this morning (forgot that and hadn't realised it 
might be
the cause of your problem ... since it just causes defaults to be 
written out
unnecessarily).

If this fixes your problem, I can see why it didn't show up on my debian 
systems
(I tested after making these changes), but I thought I did my first run 
on an
unmodified redhat system and I'm surprised it didn't show up there ... 
perhaps
an accident of timing when I ran the tests?

> 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

Yes ... I can see that ... but I don't see how it can cause corruption 
of the
database.  All it does is mean that you write out empty domains into a 
database
which was empty to start with.