Re: Significance of .GNUstepUDlock

[Ravindra]

Richard,

Thank you very much for your quick and valuable feedback.

In fact the .GNUstepUDlock is getting removed, but it is taking
approximately one minute. In our environment we need to start several
instances of our application very quickly. At that time only we are facing
the problem of not being able to read defaults. If we start our instances
one after another manually, we are not facing any problem. When we start 40
instances of that application at a time using a java application, some of
the instances were not able to read the defaults and terminates(without
crashing) giving following message

12 18 19:51:56 AlarmServer[23200] WARNING - unable to create shared user
defaults!.

It will be very helpful for us, if NSUserDefaults is updated as you
suggested. Is there a way for us know about the updations on this,  so that
we can use the updated version.

Thanks,
Ravindra.


----- Original Message -----
From: "Richard Frith-Macdonald" <richard@brainstorm.co.uk>
To: "Ravindra" <ravindra@orillion.com>; "Discuss GNUStep"
<discuss-gnustep@gnu.org>
Sent: Monday, December 31, 2001 11:53 PM
Subject: Re: Significance of .GNUstepUDlock


>
> On Monday, December 31, 2001, at 06:10 PM, Richard Frith-Macdonald wrote:
>
> >
> > On Monday, December 31, 2001, at 01:24 PM, Ravindra wrote:
> >
> >> What is the purpose of this file and whether there is any way to stop
> >> it from being created. If file is required to be created is it
> >> possible to by pass this file access, so that other instances of the
> >> application work free.
> >
> > It's a lock file to protect defaults data while it is being updated.
> > I'm not sure it is actually necessary in
> > the current implementation though.  If it ever fails to be removed
> > (other than because your program crashes),
> > that's a bug and it would be nice to get a reproducable test program in
> > order to fix it.  I have never seen a
> > copy of it left over except when a crash occurs.
>
> As I think the file is not necessary (we can use writeToFile:atomically:
> to update the on-disk defaults
> database in a safe manner), I'll probably update NSUserDefaults to
> dispense with the lock file.
> Unless anyone knows a good reason why I shouldn't ....