FileSystemPreferences lockFile0 does not close the file descriptor
on lock failure. As a result, on each locking failure 
a file descriptor is leaked, which can result in an
exhaustion of resources.

N/A

We need to add close()


  xxxxx@xxxxx   2002-04-10

We have added close() to error exit. Note for 
SQE team: No test case necessary.

I'm still seeing this error when I run my Java app.  My version 
of Java is:

java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 
1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)

I am also seeing this error in Java 1.4.1_01 on Netscape for Linux.

The problems still exists on Solaris SPARC v2.8 using JDK 
1.4.1_01-b01

Dudes, you need to fix this - it's serious. 

This bug needs to be repopened.

I found a solution to the problem from a bug fix.
The problem came from Java's inability to create the directory
where the default lock file is.
All you need to do is to make a directory
/etc/.java/.systemPrefs,
and make sure it is world readable, writable.

I tried to do a grep on the included docs, no where was it
mentioned that we need to create such a directory.

Hey ! My application isn't running and the message warning
in my log is:
java.util.prefs.FileSystemPreferences syncWorld

Please, correct this !!!!

I have installed in a Server, the IBM WebSphere Host
On-Demand 6.0 and when I access this application this error
occur.

java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build
1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)

That is the version of Java I am using and I am still seeing
the problem.

I agree with LordBrit7 that the bug needs to be re-opened.

The proposed solution of creating /etc/.java/.systemPrefs and 
making them world writable did not work.

I'm still getting repeating BackingStoreException: Couldn't get 
file lock.

Remember, I'm not running Java as root, nor should I have 
to !!!

Furthermore, my OS is Solalris SPARC 8 (v2.8) - this problem 
may not exist on Linux or other UNIX systems.

Repeat - creating those directories and making them world 
writable (chmod 777) did not work for me.

The ONLY way I can sort of stop them is set the property 
java.util.prefs.syncInterval=2000000 (or some big number).

This doesn't prevent it from happening, but you won't see the 
messages for a *long* time. 

I don't like to use this as a user forum, but this is a valid bug 
that has not been fixed and with no good solution that I'm 
aware of.

Do this as a workaround:

Set the property: java.util.prefs.syncInterval=2000000

I'm not sure if SUN is really reading this, they should.

Increasing the sync-interval makes my applications crash
with a hotspot-error after a few minutes - I can't recommend
that! :-)

I got java.security.AccessControlException: access denied 
(java.util.PropertyPermission java.util.prefs.syncInterval write) 
when trying System.setProperty
("java.util.prefs.syncInterval","2000000");

I set it using command line parameter:

java -Djava.util.prefs.syncInterval=2000000 myClassName

I've never tried setting it via code.

I hope this helps you.

I don't think SUN is reading this but how do we alert then to 
this major bug??

There is another system property 'java.util.prefs.systemRoot' whose default is '/etc/.java'.
Set it on the command line to a directory that you have control of and make a .systemPrefs directory in it.

This removed the messages for me...

The proposed soltion of creating the directories
/etc/.java/.systemPrefs and making them all world readable
and writable did NOT work for me.

Did:

chmod 777 /etc/.java
chmod 777 /etc/.java/.systemPrefs

They are all world readable and writable

When I run java, it's NOT running as 'root' !!!!!!

I'm still getting the repeating warning and leaking file handles.

You must be running as 'root'.

Sorry, I missed the part about 
setting 'java.util.prefs.systemRoot' 

However, these are work arounds and not a true solution to 
the problem.

I have this bug in Java 1.4.1 too :
java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build
1.4.1-b21)
Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)

WARNING: Could not lock System prefs.Unix error code 1246896048.
Feb 16, 2003 6:58:32 PM
java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn't flush system prefs:
java.util.prefs.BackingStoreException: Couldn't get file lock.

I work under Linux (Debian)

Hello, SUN, you reading this???
How can they claim this bug is fixed when it obviously isn't??

Hello SUN, you hear me.

Fix this already !!

jdk 1.4.1_02 prints error messages too, perhaps the file
descriptor is closed but the message.

This bug is not closed, instead its repeating a lot of times
and creating huge problems. Please don't ignore this message

I have also experienced this problem. I filed a bug
(#4838770) describing what I believe the problem to be -
that is an undocumented requirement to install a 1.4+
JRE/JVM as root. The bug has been recognized, and is
currently open.
Of course, I don't believe that Sun will want to add such a
requirement, but I'm hoping they will be forced to
re-examine the issue. Vote for bug #4838770 if you want Sun
to have another look at this issue.

This has been discussed at length in the forum as well. 
Here's what worked for me:

1. Switch to root.
2. Run my application (or, in theory, any Java code that
uses the Preferences API, if you don't want to run your
whole application as root).  You should get an INFO message
on the console.
3. Switch back to a normal user, and try running your Java
application again.  You should not see any warnings.

 - http://forum.java.sun.com/thread.jsp?forum=17&thread=271015

The people who are claiming that this bug needs to be
re-opened are referring to a different bug relating to Java
SDKs that were not installed by root (Bug #4838770) and thus
seems totally off-topic as a response to this bug.

Still getting this error on 

java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 
1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)

Creating /etc/.java , /etc/.java/.systemPrefs and adding 77 permissions to those 2 worked for me.
OS (uname -a):
AIX i2961-vm1 3 5 000B4278D600
JDK (java -version):
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)
Classic VM (build 1.4.2, J2RE 1.4.2 IBM AIX build ca142-20050929a (SR3) (JIT enabled: jitc))

Regards,
Parag P. Doke
http://paragpdoke.blogspot.com